There is a long-standing school of computer programmers who learn to code (not algorithms, not group communication, not conveying intention clearly, but the mechanical "coding" parts) from reading manuals and practicing with projects (real or "learning" or both). I'm from that school myself. People from this school tend (large generalization admitted) to learn a small core from a tutorial, and then glean the rest of the practice of coding (often, "how to use libraries") by reading manuals (a large part of the unix `man' tradition, for example).
There is also a very large group of professional, prolific programmers who learn coding through interactive exploration of APIs. This isn't just limited to interpreted vs. compiled languages (although I believed that it comes in part from the rise of teaching via interpreted languages); it also comes out of the practice of learning via auto-complete and live documentation. It also has roots in the rise of problem solving via searching on google/stack exchange/etc.
Like most communities, there are extremes: the grognard who cares why creat() lost the final `e' and thinks that X is a waste of resources might be at one end, while the front-end developer who cargo-cults together _javascript_ frameworks might be at the other. The interesting part for the discussion here is that each represents a different tendency towards "learning coding" (which even super-experienced programmers do when approaching a new system). That some people will prefer to learn by groking a manual before opening an editor and others by skimming an overview and relying on completion and searching should not surprise us. Cruically, I would go further and say that Emacs will be poorer over-all if it insists on supporting only one part of this spectrum. I think that it's fair to say that it currently leans away from the method that a large number of new coders are demonstrating that they prefer. The question is if and how far emacs is willing to change to adapt.
I hope that helps,
~Chad