Emacs is one of those systems where I've never quite understood the appeal. I'm sure this is because I've never used it for more than open/simple edit/save, but still, it seems like a relic from an age long since past. I think that its success can be attributed to (in addition to the architecture) the highly technically competent user base, along with the lack of other tools to get similar jobs done. This created a bit of a vacuum of power, and acted like a lens, focusing the technical expertise of its age upon itself. If it were not open source, I don't think that a system like this could evolve. Firstly, it would be scarce to find an organization with enough technical expertise across a large enough base of users to get beneficial functionality built. Secondly, as we have learned, software tends to model the organization that built it, so likely an organization large enough to have the necessary complement of technical expertise would also likely have a great deal of bureaucracy, leading to software with a great deal of bureaucracy, and therefore considerably more difficult interface contracts. Additionally, smart (in the traditional sense) organizations try to reduce duplication of effort, so they would likely not encourage experimentation to the degree necessary for fear that they would be paying two people to do the same thing twice.
The architecture of Emacs was very forward looking for its time. In an age where static languages and mainframes were king, Emacs dared to build an expressive and remarkably high level controller language in the form of Emacs Lisp. Emacs benefited from the simplistic terminal model prevalent at the time, in that complex user interactivity (such as is demanded today) was not common, so a very simple model could emerge. Furthermore, the pace of technology at that time was such that vast arrays of tools could be built upon that model with little demand for change in the underlying model--hence it had a stable platform. These attributes are turning into disadvantages in today's society, where advanced user interactivity and graphical interfaces are demanded. Emacs has stretched its usefulness far beyond what I would have foreseen, but I think its about at its breaking point. As the user experience at large continues to become more powerful, glossy, and user friendly, the sharp learning curve that Emacs presents, along with its antiquated model will inevitably lead to a distinct lack of future demand, and therefore a slow path to obsolescence, as its aging user base exits the mainstream of software development and technology.
As I have stated, Emacs benefited from a very simple model. This worked for Emacs, because at its conception, the very simple model, along with a small complement of enhancements, was all that was warranted. If we were to start to build a system today aimed at providing a feature set comparable to Emacs, it would be totally impossible to start in the same way. Sure, MVC is still a good choice, but users (of Emacs) accept its primitive interface as the result of a long evolution, and a new application would not gain such a nostalgic acceptance. Today's interactivity models require fundamentally more complex abstractions, and therefore growing a system from such a primitive design wouldn't work.
Avoiding complexity in implementation is a touchy subject, something that I have been grappling with in the past few weeks. As I am designing a system that requires a great deal of overall complexity, the primary questions are: How complex does the design need to be? and Where should this complexity lie? One concern that I've had recently is that as you iterate through an application's design, one has the tendency to shovel complexity around, in order to reduce the complexity of the current subsystem. If not iterated on sufficiently, the last subsystems to be visited will end up resembling the "Sweeping it under the rug" pattern, from the "Big Ball of Mud" paper. Whereas if complexity had been accepted at each level to the extent it deserved, the system would be balanced in complexity, and separation of concerns would be more clear, the desire to simplify each subsystem to the utmost leaves us with one or two complexity catchall subsystems, where the dirty laundry of all other subsystems are quietly marshaled, where they fester into an ugly tumor of the system. This is not to say that we should make systems complex for complexity's sake, but rather to not fear complexity at each step of the way.
As for Firefox replacing Emacs, I suppose that at some level, it already has (or at least the whole class of web browsers have). As they expose an MVC type framework upon which entire applications are built, the applications are becoming more and more like Lisp functionality providing the majority of the functionality in Emacs.