4. Be able to sprint through vimtutor. You have to learn to walk before you can run.
5. Never, ever use gvim. Forget about the mouse.
What does gvim have to do with the mouse? Regular console vim supports the mouse, and there are perfectly good reasons to use gvim without it (e.g., better color support, "Edit with Vim" in Windows).
Point taken re: console support. I was thinking about the menu bars, too. Many users probably have them turned off, though.
Yeah, nothing's wrong with gvim after you throw 'set guioptions-=bmrt' and a colorscheme line into your .vimrc.
Evim--now there's a crime.
I've tried to hit the right balance between being thorough and readable. There are at least ten ways of connecting mappings with modes, and double that if you care about recursive definitions. That's fine for a reference manual, such as :help, but the detail can seem daunting to the amateur user.
It's more than likely that I haven't achieved this balance in places, and if so I welcome help to clarify them.
Lastly, as I wrote on the index page of the site, this is still a draft. I published it so I could get feedback. :-)
I think you're missing the stated point of the book -- to focus on tasks not commands. The :help system can be a bit overwhelming to someone new to vim, especially if they are not sure what to search for help on. People learn in different ways, one of which is task oriented instead of memorizing commands from a manpage.
No mention of inoremap, nnoremap, etc.
If you want to learn Vim well, do the following:
1. Ask "stupid" questions on #vim on freenode. Learn to use :help
2. Use :help
3. Ask the vim-use group any questions not obviously answered by :help