Unless they're on a resource starved or crippled machine, most people are going to prefer using vim to vi -- though I have run in to people who stubbornly prefer the ultra minimalism of plain vi, even when they could run vim.

So, vim, not vi, is really what you should be comparing emacs to. Vim is far more feature rich than vi, and has plugins that allow shell integration. So shell integration is not a good enough reason to prefer emacs over vim, as vim has it too. Further, emacs' shell integration really isn't that great (contrary to many claims I've heard in the past). It's pretty buggy, with random screen corruption and many keys not working as expected.

That said, there some great reasons to prefer emacs over vim (and I say this as a vim user of about 20 years who's in the process of switching over to emacs).

The first reason is eLisp. I love Scheme and Common Lisp, and much prefer to have an editor that's scriptable in a Lisp dialect. Yes, here too vim isn't quite stuck with vimScript only. It is possible to script vim in other languages (like mzScheme/Racket, Python, Ruby, and Lua). But 99.9% of vim scripts are written in vimScript, for reasons that I guess at elsewhere.[0] There are maybe one or two vim scripts written in Python, but I've never seen one written in mzScheme or Racket (or Ruby or Lua, for that matter). So, practically speaking, the vim user is stuck with vimScript after all. That's not the case with emacs, where the entire community scripts in eLisp.

The second reason is the tight integration of many applications with emacs. You could read your email in emacs, browse the web through emacs, read RSS news feeds through emacs, etc. And when you do this, you bring the entire power of emacs to bear in customizing and interacting with these embedded applications. As a result, much of your environment becomes easily extensible and customizable through eLisp, and automating repetative or complex tasks that you perform in these applications becomes much easier as well. Yes, you might be able to do something similar in your standalone browser through Javascript, or maybe your standalone mail reader might be scriptable and extendable to a certain extent, in some language or other. But if you choose the standalone application path, you're going to wind up with a very fragmented ecosystem, programmed in a half dozen or more languages, and not very tightly integrated. With emacs, everything is tightly integrated and programmed/exteneded/controlled through eLisp.

The third reason is org-mode. Here again, vim is not completely without it, as it has some plugins inspired by org-mode. But from what I've heard, they're a far cry in capability from what org-mode offers in emacs. That said, I'm only starting to dip my toes in to org-mode in emacs, and have never tried the org-mode-like plugins in vim, so I'll stop with the comparisons here. But I will just quickly mention that I've heard of people switching to emacs just for org-mode, and after using org-mode a little, I can understand why.

The fourth reason is Guile. In the not-so-distant future, Guile will bring emacs scriptability to the next level. Many things that were painful or impossible to accomplish with emacs built on C and eLisp will be able to be accomplished with emacs built on Guile. (See here[1] for details) That said, eLisp is not going away, and is not going to be fully replaced by Guile.

The fifth reason is evil mode. Emacs can do a fair emulation of vim's core functionality. Evil mode can go a long way towards making a vim user comfortable in emacs -- and in letting emacs users edit more efficiently using vim-like keybindings. (There are probably vim plugins that try to do something similar for vim, but I doubt they do much beyond providing a handful of emacs-like movement keys.) With evil mode, you get the best of both worlds.

There are probably other good reasons to prefer emacs to vim. But those are the ones I can think of off the top of my head. There are also good reasons to prefer vim to emacs. I personally find that vim provides a more usable experience out of the box, without too much hacking. But I may be a bit biassed here. This is actually an area where both editors could stand a lot of improvement, as both do require some hacking around to get the editors to a reasonably usable state. Yes, you could do basic editing in both out of the box, but really not much more (unless you're a masochist, or RMS -- who supposedly prefers vanilla emacs).

There's also less to learn and tweak in vim (simply because it doesn't have a ton of applications that can be integrated in to it -- you are basically going to be learning and tweaking its editing capabilities only). So in that sense, learning and tweaking vim is easier than learning and tweaking emacs.. or at least you'll probably spend less time doing so. Emacs is a supermassive black hole of infinite customizability, while vim is more like a regular black hole of editing-oriented flexibility.

I'd continue making an exhaustive comparison of the two editors, but this is starting to get kind of long.. In sum, they are both great and powerful editors, and you would not go far wrong in choosing either. For me, the balance has tipped in emacs' favor, but I would not begrudge anyone for choosing vim.

Update: Yes, SLIME! How could I forget SLIME? SLIME was one of the first things that attracted me to emacs. Now I'm actually much more interested in programming Scheme than Common Lisp (at which SLIME is primarily aimed at). But emacs also supposedly has some nice REPL integration with Scheme as well, including via SLIME.[2][3] It also has parens mode, which makes editing sexp's so much easier than they would be on vim (to my knowledge). That said, vim also has some REPL integration plugins, like Nekthuth.[4] They're not nearly as powerful or well integrated as SLIME, however.

[0] - https://news.ycombinator.com/item?id=5681534

[1] - http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg006...

[2] - http://www.emacswiki.org/emacs-en/Scheme

[3] - http://www.doof.me.uk/2010/12/12/using-slime-with-chicken-sc...

[4] - http://www.nekthuth.com/