Vim is a regular expression system hooked to a 1970s user interface. If you need to apply regular expressions to text files, vim is useful. I used vi to write code for years, but that was decades ago. There's been some progress since the 1970s.
First, efficiency of bandwidth over an ssh connection. You might think, "Oh but there is tons of bandwidth on the internet today". However, I actually use vim to pair program with people in the UK while I'm in Japan. Vi commands can easily deal with variable latency and still give good performance because you are almost always in command mode. Instead of arrowing down to some character, I simply tell the editor where I want it to go using a language with a grammar. I have very happily coded all day with 300+ ms latency in Vim. For me this is a killer feature that is painful with any other input system. (vi is even better at this because it reduces the number of repaints to a bare minimum).
The second feature is very much related to the first - the use of a grammar for describing what you want the editor to do. With most editors, you press a key and it does something small and specific. With vi/vim you describe things that you want the editor to do with sentences.
This is a great example of the difference between ease of use and ease of learning. vi/vim is very difficult to learn well (or at least it takes a lot of time and practice). But it is arguably much easier to use once you have that learning. It's like the difference between "Pick up glass. Drink beer." and "Move hand. Move hand. Move hand. Grab glass. Lift glass. Move hand. Move hand. Move hand. Tilt glass. Drink beer".
Sure, it's not for everyone, but it's clearly not reasonable to say that the state of the art has improved in these respects. I can think of no other editor that even attempts to solve these problems. If you know of some, I'd be happy to learn of them.
One thing I used to do is visit http://www.vimgolf.com/ and compete with the best solutions there. Aside from a higher usage of meta characters (which is a modal vs. quasimodal thing, rather than a sentence vs. select thing), my editor of choice (Sublime Text) rarely lost out.
There is the caveat that some things that are great for golfing are relatively useless elsewhere (eg. numeric modifiers) and vice-versa (command panel: trim trailing spaces). I miss the later in vim much more than I miss the former in typical editors... although I still hacked it into Sublime anyway.
Probably my example was a bit poor. I wasn't trying necessarily make the argument that Vim is more keystroke efficient than other editors. I used Emacs for 20 years before I switched to Vim and I was quite efficient with it. I was more trying to convey the idea that the way of thinking was different. Instead of concentrating on the immediate motion of the cursor, I'm concentrating on the structure of the document.
Lately I've been thinking it would be nice if someone were to think a bit more about extending the state of the art in modal editors. Vim was a nice extension of vi, but the grammar is still pretty crufty in a lot of places. It would be cool to rethink it from scratch, I think.
In what way does the multiple selection model not concentrate equally on the structure of the document? It's true that vim has a larger vocabulary than a typical editor, but its grammar is actually weaker. For example, I know of no way to combine two arbitrary motions.
Consider the case where you want to delete all strings containing the word die, where the string grammar is non-trivial. In a selection-based language you can
* select-all-"die", manually checking that they're inside strings
* select-enclosing-block
* delete
If one had a language-aware string token finder (and, frankly, a token-aware editor would be amazing - maybe I should edit Sublime to do that...), one could even
* select-all-string-tokens
* select-all-"die" inside selection
* select-enclosing-block
* delete
This is a very structural approach. I don't know a neat way of doing this with vim. (I'd be happy to learn I'm wrong!) There are other examples, like where one wants to work on some collection of things in lockstep and vim's inability to hold state through selections between commands results in a difficult workflow. The multiple selection model remains semantically unperturbed.
I would very much be interested in a modal editor that doesn't just try to copy vim - working on multiple selections with a large vocabulary and syntax-awareness would be wonderful. I also find some things, like temporarily restricting actions to a subset of selections, needlessly hard in Sublime. There's a lot that can be done!
Speaking of token aware editing, smalltalk had an AST aware "editor" called a "refactoring browser". It could even infer the type of a variable by running tests and seeing what type the variable held in the running code. This is where you can get some crazy utility happening with automatic refactoring. Unfortunately most languages these days are needlessly complicated to parse (ahem... ruby).
I am toying with the idea of writing an Evil like mode in Emacs that gives the utility of vim, but without some of the cruft from vi. I think Emacs is a good platform to do it in since it gives you a lot for free (especially a nice lisp interpreter to implement features in ;-) ). However, I have far too many things on the go as it stands :-(
Incidentally, there is nothing inherently wrong with 1970's user interfaces. My car still has a steering wheel just like cars did in the 1970's. And there is a reason for that. Because it works really well.
I'm not really a fan of what passes as IDEs, either, but I generally am not attached to any particular editor and hop around them.
(The right answer to vi vs. emacs is, of course, Acme.)
Even if you agree with vim's approach to modal editing and object motions, there is plenty bad to be said about it in light of some of the tools we have available to us today. But humble origins do not always lead on to humble ends. There is no use in calling a book bad and giving as your reason that it was once pulp. It would be just as unhelpful to call the Lisps of today slow, and to use as your crutch the old adage that "LISP programmers know the value of everything and the cost of nothing."[1] As GP said, "There's been some progress since the 1970s."
[1] https://en.wikiquote.org/wiki/Alan_Perlis#Epigrams_on_Progra...