The article claims that "Emacs’ big idea has been thoroughly learned", but I beg to differ.
Having an extension language which lets you define functions and bind them to keys does not make you "Emacs". The big idea of Emacs (which of course it got from the Lisp machines) is self-hosting: Emacs is written in Emacs Lisp. There is no separate extension language. Yes, there is a core written in C, but it is very small, and there is an ongoing effort to move functions from there to Emacs Lisp (lots of stuff was put in the C core for performance reasons, but nowadays our machines are just so much faster).
Since it is all interpreted and Lisp, you can redefine anything at runtime, down to the core (which of course implies that you're free to render Emacs unusable without any problems).
Emacs surely isn't alone here; maybe Atom works the same, and I guess LightTable does, too. But he mentions SublimeText, which doesn't work this way. I think we're still far away from "thoroughly learned".
In that, Emacs is very close to Smalltalk environments. Everything you see on the screen is a Smalltalk object and its behavior can be redefined at will. I'm not sure how much the design was influenced by Lisp machines or Emacs itself.
I once crashed a Squeak image by telling it "true := false".
Since then constants became a little more constant.
As I've written, there is a core written in C. The ratio of Emacs Lisp vs C is about 80/20. 20% might look rather large at first, but if you keep in mind that Emacs supports a large variety of operating systems (from MS-DOS(!) over Windows, OSX, Linux, *BSD to various other Unix flavors like AIX and Solaris), and also supports various toolkits (like Lucid/Athena and GTK), it actually isn't that much. Most of the C code works as a sort of hardware abstraction layer, providing a common interface to the Lisp layer for handling (bidirectional) display, processes, memory, and so on. Compared to that, the actual Lisp interpreter is tiny.
