I've noticed two interesting things about Emacs over the years. One is that it's an order of magnitude easier to write tools in Emacs than in other environments. It's also more satisfying, because Emacs lacks the arbitrary hoops you typically have to jump through when writing plug-ins—hoops that come from internal limitations of the host system and give you that annoying "why can't I do it this way" feeling. Emacs, despite its high learning curve, has little such systemic friction. Because making tools is an order of magnitude easier and more satisfying, people do it more, which is why Emacs has so many tools, as well as sophisticated things (e.g. Slime) that show up more rarely elsewhere.

The other thing is that the core of Emacs is a masterful piece of domain-driven design, where the domain is "text editing and windowing". Its conceptual model is clear, simple, and consistent. (Some of the later additions don't have this quality, but fortunately they mostly stay out of the picture.) It has a rich language for its concepts—'buffers', 'text properties', and so on—and uses that language everywhere through documentation and code. This tremendously eases the burden of writing programs that interoperate, because everything is based on the same conceptual model and thus makes sense in the same way. Not all Emacs programs follow identical conventions—far from it—yet it's amazing how close they get, given how many there are. It's Emacs' exemplary domain model, as much as its Lisp character, that creates this conceptual unity.

So while Emacs rightly gets a lot of credit for the technical aspects of its extensibility, we should hear more about the design aspects. Its core design is a masterpiece and ought to be studied as an example of the power of software design itself—something we're mostly still pretty bad at. It might be hard to get that taken seriously, though, since on the surface Emacs is obtuse, clunky, and old. Only when you dive underneath does it become orderly and beautiful.