When I read some of the "tips" for using Vim, I find myself perplexed. For me, Vim is a tool to solve some other problem; one that involves whatever programming language I am using Vim to edit. I don't want intellectual challenges from my text editor. There is a balance in all of this. It is beneficial to learn about efficient ways to edit code. And if you want to make a game of "Vim golf", there is nothing wrong with that.
One of the great benefits of a visual editor (once called a "screen editor" is visual feedback. I rarely count words or give a count to Vim. I do something like "dw" to delete a word, then repeat it using "." and watch the screen for the desired effect. If I overshoot, I use "u" to undo changes. Just as often I use "x" to delete characters and hammer away until the job is done. The point here is that I don't think at all, I just do it -- my thoughts are on what the final text needs to look like.
So muscle memory combined with visual feedback is what using an editor is all about in most cases. This changes when I am faced with a situation that has a bunch of edits that I can see fit some pattern. I may do an edit of the first line, then "j." to move to subsequent lines and repeat the change for as many as 10 lines, but for 100 I start thinking of ways to automate the process. In these cases, other sorts of Vim tricks come into play. Often I use command line mode, and in particular the g, v, and s commands. But I usually edit for days and weeks before I need to employ these sorts of tricks.
Tom's vim pages / tom@mmto.org