This may just be me, but I feel that a lot of the productivity that Vim supposedly creates is a result of programmers spending lots of time learning one tool very well, as opposed to something inherent within Vim that automatically makes you more productive.
That's not to say Vim doesn't have an excellent ecosystem, and has tried and true ergonomic benefits, however I feel that if someone spent the same amount of time learning, say TextMate (just an example, may not be the best), they would be just as productive.
Absolutely not true. The best description for VIM is "programming your text". In VIM you have a set of commands that you use to manipulate text. Generally commands looks like nOm where n is number of times to repeat the whole thing, O is operator to apply, m is motion command/selection. So for example 3dw applies 3 times the d (delete) operator to motion command w move one word forward, i.e. delete next 3 words. The nice thing is if you learn lots of motion commands you instantly learn lots of ways to manipulate text objects based on those motions. Want to change inner if block in your code? Just type ci{ (change inner { which deletes everything inside the {} block the cursor is in and places you in insert mode. Etc.
In other editor you have keyboard shortcuts and there are only so many you can have. In VIM there are over 1500 commands (not shortcuts). People who say "vi key bindings" or "vi shortcuts" don't get vim.
My favorite form of this is when using regular expressions.
You have 'v' for visual mode, where you move the cursor around and can select stuff.
You have 'd' to delete things.
If I press 'v' then move around, then press 'd', I'll delete the selection.
If I press 'vf,' it means 'select until you are on a comma'.
If I press 'df,' it means 'delete until you are on a comma'.
The problem with these two modes is that they're restricted to one line.
Now if I do 'v/,$', it means 'select until the first match of the regular expression ',$' (comma on end of line). If that comma is 5 lines below, it'll find it.
What's fun is that with this sublanguage, I can say 'dv/,$' and it will delete where the selection of the next comma at the end of a line, or more generally, <Command>v/<Regex> will do the command until a given regex. If I replace 'd' with 'c', it deletes and puts me in insert mode ('c' is change), and so on.
Even nicer? what if I'm writing Erlang (I usually am), and I want to delete, say 3 functions. I could delete one by getting to the beginning of the function and delete until '\.\n' as a regex (functions are terminated by a full stop). So the command becomes 'dv/\.\n' for a single function.
Rather than calling the same command 3 times, I can do it once, then press '.' twice to repeat the previous ones.
Or I can use the fact that vim has this sublanguage and instead call '3dv/\.\n', which will delete until the next end of a function (full stop + line break) 3 times.
Its command set is fully composable and at some point you find your sweet spot in there.
Yes, it's true that it can be done in any sufficiently good scriptable editor. But once you have written all those scripts to do all those magic, your editor will look more like vim.
I will grant that "vi shortcuts" is strange, but "vi key bindings"? The operators/motions (or verb/noun) perspective is vital, but those operators and motions are not intrinsic properties of the keys they happen to be mapped to - indeed, you can remap them. The initial mapping is a totally valid question, particularly for lesser-used commands, and one that can quite reasonably be referred to by the phrase "vi key bindings".
I find SublimeText (and TM to a much lesser degree) have certain features that really help with efficiency, like multi-line editing and good key shortcuts for in-file search and replace and regexp replace.
Vim is like this but without having to take your hands off the keyboard, so you get a little extra. But using the mouse and having a very visual hand-eye-coordinated text editing representation is really intuitive, so it's definitely a tradeoff.
Vim takes a long time to get used to, is not intuitive, and gives an extra boost in speed by its very nature; pretty much comes down to that.
Sort of like a car: it takes a long time and investment to learn how to drive and get used to the completely new world of streets and driving rules, but once you're there you can get places way faster.
All that said, I still use SublimeText, because I don't necessarily need Vim to program efficiently (I admit, my main obstacle is my mind, not my editing speed), and the experience of SublimeText is very efficient and matches my intuitive mental model of text. So the moral is, use what works for you.
You might feel that way, but you're probably wrong :) Vim basically is the logical result of taking the idea of "how can I manipulate a text buffer efficiently using my keyboard" to its conclusion. Once you've burned in the muscle memory using arrow keys and a traditional buffer with the mouse is like having your hands chopped off.
I would imagine that with something like TextMate you'd soon reach a point where you pretty much know all the shortcuts. With Vim, it seems like this saturation point never happens, even if you use Vim proficiently for years there is still more you could learn and incorporate into muscle memory for better results. It even surpasses the "collection of shortcuts" that many editors are and becomes almost a programming language for text editing. It's uncanny how Vim posts like this inevitably reveal commands and methods I'd never known before, and I thought I was a Vim expert.
In some ways, Vim programmers are stuck in a local maxima of efficiency - we're really efficient at doing edits like "search for and change this word" and "change parens to square brackets" - but if you look at the sort of advanced features that other editors have, you find that they don't care about those edits, and have chosen to automate different tasks:
Example 1: TextMate users create bundles that drop in common boilerplate easily, and they have a really nice ways to jump between files in a large project. Vim users mostly don't do either of those.
Example 2: IDE programmers tend to have syntax-aware tools that implement common tasks like "extract local variable" or "jump to implementation". Vim versions of these tend to be crude approximations that use regexps instead of actually parsing files.
Personally, the cost of typing more slowly and having to use a mouse to edit text means that I haven't ever learned to use modern editors effectively - so I'm faster as an expert in Vim than I am as a novice in Eclipse or TextMate or IntelliJ or Sublime - but in many situations an Eclipse expert is probably faster than me.
It takes more effort in vim, but for each example you've mentioned some vim user somewhere stopped and thought, "That's useful I wish I had that AND had it in vim."
Picking up Android development is the first thing that really made me consider switching out of vim. With eclim, I'm now half in half out. I do most of the actual coding in vim with eclim doing the menial work of basic error checking, automated imports, automated refactoring, etc. For debugging, and some of the layout tools I'll switch to the Eclipse instance that's already backing eclim and do it there. It's a nice compromise.
TextMate's learning curve is desperately short and flat. After 2 or 3 months I knew everything there was to know. The only dark corners could be found inside language-specific bundles which made them rather useless.
I've used it non-stop from late 2006 to late 2010 and I can attest that the last three years were extremelly boring. On the other side, 2 or 3 months is the time needed to have a firm grasp on the basics and, after 1 year and half, I still learn new tricks every day.
If you want inherent advantages, don't look further than Vim's modes and its language.
That's not to say Vim doesn't have an excellent ecosystem, and has tried and true ergonomic benefits, however I feel that if someone spent the same amount of time learning, say TextMate (just an example, may not be the best), they would be just as productive.