There's no reason that somebody's first exposure to bare-metal programming should be with the ISA they actually want to understand
in practice, though.
Although no obvious example is springing to mind (any help?), I'm pretty sure there are cases where it's faster to teach someone—even an adult!—a https://en.wikipedia.org/wiki/Lie-to-children model of a system, and then teach them the actual system, than it is to teach them the actual system from the start.
I believe that, for the same reason I believe that people get better at the reflex skills of a video game if early parts of the game hold back some of the game's mechanics, focusing on only a core subset. You're allowed to develop just those sub-skills in isolation, and get good at them, so that they can become subconscious-enough that you won't be distracted thinking about them any more by the time the new sub-skills are introduced.
Honestly, I think a great way to learn bare-metal programming would be to not work with bare-metal at all, but rather to work with a virtual machine for a custom ISA, where that supported ISA has 100 different sub-variants (ranging from very simplified to very "realistic") and the VM supports all of them. You'd learn to work with the simplest ISA (e.g. target a compiler backend to it), then learn the next-simplest (and tweak your compiler to also emit the new instructions introduced), etc. Evolve from RISC to CISC, from stack-based to register-based, from SISD to SIMD, gradually add vector instructions, etc.
By the end of a process like that, you'd understand a (fake) ISA nearly as complex as x86-64; but more importantly, you'd understand the why of it, not just the what. You'd understand the history behind each instruction, and why it has the options/limits it does. At that point, learning x86-64, or AArch64, or whatever else, would just be "learning the vocabulary", with no new skills per se.