If you have a conventional programming background (and are long enough in the tooth, as I am) it feels a lot like programming in BASIC vs programming in assembly language, back in the 8-bit days.
I should say that I am speaking as someone who originally learned and dabbled in I6 many years ago, without ever becoming seamlessly fluent, then recently moved on to I7 with a lot of doing bits and pieces in I6.
Back in 8-bit days, the most common reason for using assembly language was that BASIC was too slow for many purposes, albeit BASIC was closely integrated into most machines and an order of magnitude quicker to write and easier to use. Speed of execution isn’t really an issue with I7 unless you’re targeting VERY old hardware, in which case the greatly-increased memory requirements of I7-compiled stories make it impractical in any case. But there were also always things (usually to do with direct interactions with hardware) that BASIC just couldn’t do, and therefore assembly language or direct machine coding were required: the corollary is true with I7 vs I6- which of course is very close to C rather than assembly language in both aesthetic and syntax, but the analogy largely holds.
As you’re probably already aware, I7 is compiled to I6, so by definition you can do everything in I6 that you can do in I7- just as you can do everything in assembly language that you can do in BASIC. But some of the very neat things that I7 code does almost effortlessly will be very time-consuming to separately implement and debug in I6.
The current developers of I7 make noises gently discouraging mixing of I6 and I7, with veiled threats (some inadvertently crystallised in the latest Ver 10) of restricting the possibilities of ‘hybrid coding’ in the future. Conversely, they have made little or no progress in recent years in developing I7 to enable things which currently still require I6 achieve- their not inconsiderable efforts having been directed elsewhere.
As has been mentioned elsewhere, looking at and modifying the I6 code compiled from I7 can be invaluable in understanding why I7 code is not behaving as expected- although this is chiefly as a means to working out whether the observed behaviour is an error in documentation, compilation or I7’s underlying I6 code base and libraries. It does also offer the means to apply I6 patches to bend that misbehaviour to your will. You will find numerous examples on this forum if you search for ‘bug’.
My suggestion would be to learn I6 first- I think you will likely enjoy your I7 experience more if you do. But then give I7 a go and see whether you like it. If you do, your I6 skills will be far from wasted.
The aesthetic and mindset of coding in I7 and I6 are chalk and cheese and you will find yourself naturally gravitating to one or the other, but they are so different you probably have to develop a full project in each to come to a conclusion. I can reassure you that they are both fun!