Other editors have kind of standardized it to associate a language to a command to run and communicate trough the stdout/stdin. Why do vscode need to be more complicated?
(even this association could be done with a local DB similar to mime types if we wanted to simplify)
The approach that you mention has its limitations, and what many (most?) editors do is quite a bit more complex than that.
For example, I don't want a new LSP instance for each file, I want to re-use the same LSP instance if files belong to the same project. For this, my editor needs to understand which directory is the root of the project, and this varies per-language.
In case of neovim, there's a nvim-lspconfig plugin that ships all this configuration and lots of other little nuances. I guess the folks from VSCode preferred lots of little plugins instead of a single big one.
I'm pretty torn, on the one hand this tight vscode integration should exist, and is being used to good effect by projects like the lean info-view, which shows the goals of the proof state. And my own project which e.g. generates railroad diagrams and displays them in the editor.
On the other hand, it is kind of unfortunate that this sort of tight integration with language server and editor is happening in the editor which drives/governs the specification itself. I think it would be much more tolerable in regards to the future of the specification if these sorts of "above and beyond" integrations were all happening in any other editor.
(even this association could be done with a local DB similar to mime types if we wanted to simplify)