I could even argue that since Emacs hasn't been phased out (and still has a decent user base) that it does something that other text editors don't (or can't) do.
In particular, the biggest change I'm aware of with Emacs Lisp (the language) is that we now have lexically scoped variables. The biggest change to its implementation has been a push towards native compilation (much improved performance, I like it). The language has, otherwise, largely remained the same.
In some regard, this can be seen as a consequence of having a decent base language. Where Fortran's original version became increasingly indecent as time went on, Emacs Lisp seems to have held up better thanks to a stronger foundation. That doesn't mean there isn't room for improvement.
In particular, the things that (my opinion) are still missing from the language are:
1. A good concurrency model. CSP, actors, I don't care but it needs to exist. Paired with the native execution we're getting now, this would greatly improve the real and perceived performance of the system.
2. A real module system. I'm not talking about a package manager, but moving things into module scopes a la Common Lisp packages. The prefixed names for functions and variables is a hazard. Even if you leave every symbol exported by default so that you don't lose visibility to module internals it would be better than now. It would also open up a lot of opportunities like the potential to run multiple versions of the same package side-by-side.
And yet most Fortran programmers reject/ignore those changes and stick to Fortran 77. When I was in academia, I couldn't find a single person writing Fortran code in anything newer than 77.
Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66). Specifically, that's the version that got structured programming elements added to the language. Having once inherited some pre-F77 code (well, it was F77 by the time I got it, but was started before then and that was obvious by its almost complete lack of structured programming), I can say that F77 is a substantially improved language over the prior versions.
That's because FORTRAN is one of the oldest languages, and you'd expect lots of changes as the whole field develops. If you use that as a metric, most languages will appear stagnant. Python hasn't changed much in the last 20 years, for example.
One might think Eclipse IDE is old. But Fortran predates the three-point seatbelts. The Vietnam War. Berlin Crisis. The Space Race.
(1) Except that one old beard who was convinced F77 was the ultimate, and everything newer was crap.
This is definitely the biggest pain point, especially as people go to expand their use of Emacs (e.g. with Doom, adding more modules and integrations, one has to be careful to lazily evaluate config blocks to avoid loading everything at startup).
Even without such extensive configs, working on a large repo with a slow I/O (e.g. some network mount) with magit will cause large pauses once a command finishes if it has to refresh the magit buffer, or trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.
I do at least look forward to Emacs 28, which iirc is going to get native-comp (although that is already available as an experimental branch perhaps?).
Please try `org-ql` and `helm-org-ql`; these newer search tools perform better than `org-rifle` and generally supersede it.
No matter what, emacs still feels "alien" in my OS's desktop interface with its UI concept, and never fully integrates. That's fine if you don't want it to integrate, but I actually like some concepts of my OS's UI a lot, and miss them in emacs.
And elisp is not a very good language, born of a time where programming languages still had a long way to go (at least in the mainstream, academically it always seems a bit different to me). They are actively trying to fix things, e.g. the adoption of lexical binding, but the scope of this effort also shows how emacs is a very big ship that is hard to change course.
Someone else mentioned lack of proper multi-threading in another comment now, and this is also very noticeable.
>Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world.
I was really responding to this. You're right though: there are aspects of Emacs that are dated, the UI isn't very spiffy, and I've never dealt with elisp before so I'll take your--and everyone else's--word for that. I was just suggesting that it gets the job done for a lot of people and maybe, as a result, shouldn't be classified as outdated.
I wonder if there will be a way to sidestep these limitations or if something in the language semantics would forbid it (e.g. the way Python is basically limited with the GIL because current updates are basically not tolerated by the semantics).