TL;DR: Watch this video: the stated reasons for switching are very similar to my own. It wasn't until I watched this video and read the book that I took the plunge to switch to emacs. It was the fact that with emacs I could have vim _plus_ much more and better functionality.
https://www.youtube.com/watch?v=JWD1Fpdd4PcI'll have to write a blog post about it sometime, but basically while I absolutely _love_ the vim 'editing interface', that is, not the GUI, but the modal editing, the bindings, motions, objects, relative line numbers, and so on, everything else aside from that, primarily plugins, always felt like ad-hoc hacks to me. I've contributed to a couple of vim plugins so I've seen it first hand, to the point where plugin authors I've worked with have expressed feelings of wanting to switch to emacs to just make things easier. Indeed, some have, such as the vim-airline author [ http://bling.github.io/blog/2013/10/27/emacs-as-my-leader-vi... ].
Whereas plugins in vim oftentimes gave me the impression that they were stopgaps and hacky workarounds to get vim to do something it wasn't meant to do, emacs packages feel very natural, comprehensive, and well designed. Just take this article for example. As awesome as vim-fugitive is for vim, I feel that it's good _for being a vim plugin_, but it has _nothing_ on the equivalent on emacs: magit. Take a look at it's comprehensive documentation: http://magit.vc/ Or flycheck's [ http://www.flycheck.org/ ] documentation here [ http://www.flycheck.org/manual/latest/index.html ]
It seems like everyone puts up with everything else about vim just to have the good parts of vim that are generally very poorly emulated by other editors. The evil package for emacs changed that for me, as it's the most faithful vim emulator I've seen. Now I have a superset of vim; the vim that I love in an environment that is _much_ more suitable for my development workflow: magit, error checking, tags, searching, and more.
If you're just a vim user, you probably don't really think about or realize what you're missing out on by not using emacs. One of my favorite things about emacs that the book really emphasizes is that it is completely self-documenting. Every function, every key binding, every command, every variable, everything is documented and easy to find. Vim of course has `:help` as well, but emac's documentation is on an entirely different level. I can press `C-h k` for example, then press a binding on my keyboard, and it'll tell me what command I have it bound to, what that command does, and it'll have a link to the source code for that command that opens in emacs with syntax highlighting and everything. Of course I can also do the reverse: find what key a command is bound to; in fact I can search my bindings as I type using helm-descbinds. I can search emacs documentation easily with the `apropos` command and its variants. Oftentimes in vim I generally only looked things up only after I already knew _what_ to look up, whereas in emacs I can easily explore things on my own and figure things out.
Emacs has much better extensibility features in general. In vim sometimes I would find something a plugin did that I wanted to work differently, and I pretty much only had two options: 1) file PR and hope the author agrees with my changes or adds them in optionally or 2) fork the plugin. 2 was out of the question because I didn't want the maintenance burden of maintaining a fork, and 1 was too much trouble sometimes for simple modifications or were simply too opinionated to realistically be accepted by the author. So pragmatically I just treated plugins as set-in-stone. With emacs I have much more options at my disposal ranging from advising [ http://www.gnu.org/software/emacs/manual/html_node/elisp/Adv... ], hooks, and in the worst case just redefining symbols with emacs lisp.
I was and still am hopeful for Neovim, but it'll take ages for it to catch up to emacs in terms of robustness and ecosystem, let alone similar feature set of emacs (which is probably a non-goal of neovim anyways). It's just an entirely different 'environment' in the sense of features and packages available to you.
I wonder if in the future we could leverage neovim's API functionality to have completely true vim bindings/editing within emacs. That would be the absolute best case scenario that I could imagine.
That said, I definitely believe that the default emacs bindings are horrible. I at first wanted to try to go cold turkey, 100% emacs, but the editing in emacs is just horrible to someone like me familiar with the speed and precision of vim editing, so I gave in and used evil, which is amazing. That saying about emacs being "a great operating system, lacking only a decent editor" rings very true to my ears, and with evil I have both.