I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.
- No support for threads or any other concurrency model. Any I/O and the entire UI freezes, no matter how many cores you have idling.
- Even on a single thread, the runtime is generally several times slower than comparable modern scripting languages. The GC is not so great, either.
- The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".
- Elisp is the worst Lisp dialect I've ever used. No packages or namespaces. No bignums. Weak regexes, using a syntax completely incompatible with any other. It's improving but very slowly. It finally got support for lexical scoping a few years ago.
Except for the generous contribution of Unicode support, it feels like a system whose technical attributes were not even terribly impressive for the 1980's. Emacs is truly greater than the sum of its parts. It has to be, because each part is worst-of-breed.
It has pros and cons.
The pro is clearly that in Emacs everything is text, and can be processed as text, by using the same commands, keys and macros you use for everything else.
No other editor has this, and I cannot understate how handicapped I feel in those editors where some things are "off limites" and cannot be copied, because it's a designated "GUI" of some sort, instead just... text.
Taking that away from Emcas would IMO be a major loss.
And as an editor it is quite slow/sluggish.
Also when using ssh to a web server over my slow connection I can run emacs but it's obviously redrawing the screen when I change the buffer, vi is much more responsive.
Also (may be different from your use case), using tramp-mode has mostly eliminated the need to run the emacs inside the server, I run it locally and fetches files using ssh.