When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually.
When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool.
Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.
It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree.
So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes.
An efficient text editor with completion + powerful refactoring. This is the winning combination.
Text programs are pretty efficent when writing, editing code, because you can access a large number of elements quickly with the syntax.
E.g. writing let a = 3 can be much quicker than starting some command palette from the keyboard, choosing the "declare variable" action and then fill some dialog with the name and value of the variable.
I have doubts it can be made as efficient as typing, otherwise we would have seen such prototypes already. Have you?
PyCharm: Yes
VS Code: Yes
Eclipse: Yes
The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you!
I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination.
I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode.
The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.
Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors.
Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.