I'm still using and loving Vim, and still believe that most advice about learning it doesn't work very well.
A few new points of disagreement:
Too much emphasis is placed on speed. Vim is fast, and that's great, but users will feel enough pressure to go fast on their own. It's probably counterproductive to say or imply that hesitation is the sign of a weak user.
This is particularly true because it will push new users away from learning and toward trying to type the things they know faster. It's hard enough to communicate just how big and feature-rich it is.
Relatedly, but conversely,
vimtutor (which I respect and like) and other beginners' tools should do more to make beginners at least aware of tools like the jump list, the change list, marks, and the quickfix list. They probably won't use all these tools very soon. (Probably most seasoned Vim users don't use all of them.) But they are great tools for giving people a sense of what Vim is all about and what it can do. So, instead of introducing a complicated and metaphysically dubious notion of a "grammar of Vim" or similar, which can leave learners feeling like they are missing the point if they don't intuitively grasp (e.g.) which commands take a count and which don't, we could just say things like: "There's this thing called the jump list; it lets you go back to the last location you jumped from, and the one before that, and so on, back and forth, as you wish."
I suspect that the deeper mistake here is assuming that users need to be fluent in the exact definition of X before showing them a feature involving X (so, that they need to know the definition of a jump, a change, or a motion before they can be shown tools that use these concepts). It's an intuitive thought, but I think it's wrong in this case. Probably nobody knows, for every service they use that supports undo functionality, the exact rules governing how actions are chunked into units for the purposes of that functionality. They still ought to know that undo exists.
The best mental adjustment I've made recently as a Vim user is, when I hesitate or get a little confused, to ask myself: "What do I want to do?" Whether or not I'm interested in Googling to learn a new Vim thing right then, just saying it to myself tends to lead me to a good answer. (Often it's something like: "Go back to that file I just had opened" or "put an asterisk in front of each of the next 8 lines.") It's like rubber duck debugging but for editing text instead of coding.
More posts about programming