<i>You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click"</i><p>I have used XCode, Eclipse, and Visual Studio.  Emacs' tag
functionality is much easier to use than the equivalent functionality
in those editors.  ("C-u M-." and "M-star" are especially convenient.  And I would have typed an asterisk there, but news' parser is busted.)<p>The parentheses awareness he is talking about is paredit-mode, which
changes Emacs' usual keybindings from operations on lines to
operations on S-expressions instead.  I never got the hang of it, but
Emacs' built-in word/sentence/paragraph movement/editing functionality
is essential.  I have not seen these features in other editors,
including Vim.<p>The other feature that Emacs has over the "visual" editors that you
mention is the ability to interactively change how the editor works.
(This is especially nice if you're a lisp programmer, as there is
nothing to be confused about; it's just Lisp.)  I am not just talking
about changing the colors or things like that, I am talking about
writing new modes, changing the built-in behavior, and so on.  I do
this so often I don't even consider it unnatural.<p>(Something I fixed today; when loading a ".chs" file into the inferior
GHCI buffer via C-c C-l, GHCI complains "this is not haskell", which
is true.  Then it changes the prompt from "My.Module&#62;" to "&#62;", which
makes the next C-c C-l command lock Emacs.  I debugged this by seeing
which command C-c C-l ran by pressing "C-h k C-c C-l".  I then pressed
ENT to visit the source code for that function, and noticed that it is
programmed to hang until it gets output from GHCI that matches a
regex.  I changed the regex to something more liberal, hit C-M-x to
load my changed function, and my problem was solved.  Those two
minutes of distraction will save me much frustration over the course
of the rest of my life.  When was the last time you fixed a bug in
Eclipse or Visual Studio in two minutes?)<p>But anyway, Emacs' functionality is not limited to Lisp.  I mostly
write Perl and Haskell, and Emacs excels at both tasks.  It is also a
good mail reader, web browser, and IRC client.  (Why yes, I <i>am</i>
composing this in Emacs.)<p><i>allow interactive step-by-step debugging with variable watch, disassembly, stack trace, etc - I shouldn't really name all the things that are possible in a typical modern IDE</i><p>But of course, no REPL.  I still don't know what a C++ programmer does
when he wants to figure out what regexp he needs to match something.
Write a driver program around the library, compile it, debug it,
recompile it, and finally run it and play with it?  Sounds fun...<p><i>A compiler which doesn't "enable very fast code" has no place under
 the sun nowadays.</i><p>Apparently the real world is not under the sun.<p><i>Memory footprint: megabytes do matter because of the CPU cache. A 30,000 LOC program should take a few megabytes at most and fit a modern CPU cache entirely. Compared to a 50MB program the performance gain can be enormous.</i><p>Sure, but you have to realize that most applications that people build
with big stacks like CL or Java or C# or whatever are not really
CPU-constrained; the context switches kill them.  (Wait for user to do
something.  Wait for database results.  Wait to copy response buffer
to web server.)<p>Nobody wants code that runs slowly, but the trade-offs to get
something really fast (or to fit in the CPU cache, etc.) are not worth
the effort for most people.  "80% solution" and all that.  And, the
CPU cache is all about critical sections, anyway; it's usually your
data that doesn't fit in cache and slows everything down.<p>So anyway, you are underestimating the capabilities of Emacs.