[omnicognate]

Sounds like you're unaware of LSP (Language Server Protocol). "Proper code intelligence" is absolutely something that an editor+plugins can provide, and LSP means that intelligence can be developed once and used with many editors, rather than "integrating" the editor with the code analysis so your choice of one dictates your choice of the other. LSP is just one of those things that makes sense, turning something quadratic into something linear.

I don't care at all if someone prefers IntelliJ over Emacs (that's a pure matter of taste) but the idea that it's impossible for an editing environment that isn't delivered as a single, integrated monolith to expose powerful language-specific tools such as interactive lints, large scale refactorings, debuggers (check out DAP for the debugging equivalent of LSP), etc was never true as a technical matter and is increasingly untrue in the real world.

One of the best developments in dev tooling in recent years is that it is starting to be seen as the norm for new languages to provide canonical language server implementations. Long may that trend continue.

[Constellarise]

Language server protocols are just re-inventing IDEs, but instead of using shared memory and interacting with the compiler directly you have to use an inefficient JSON pipeline.

[omnicognate]

No, the choice of a client/server model was a design decision, one that is not unique to LSP and is also used by some IDEs for various reasons (see, for example, JetBrains Rider). Performance is absolutely fine - the only data that needs to be transferred is that needed to drive the UI, which is trivial over a local socket. Had that not been the case, there are plenty of ways LSP could have been designed as an in-proc library interface and remained just as open as it is.

What makes LSP not 'integrated' in the sense of the I in IDE is the fact that it is decoupled from the editor, allowing one editor to work with many language servers and one language server to work with many editors.