Language support is tricky. Libraries and services implementing it will have bugs, memory leaks, etc. ultimately leading to crashes. I'd prefer my text editor not to crash erasing my unsaved changes. So probably the language support should be isolated in a process separate from the editor.
Of course, an LSP client will also have bugs. When I tried LSP support in Kate editor last year, it crashed together with the language server. Emacs at some point (could be after a language server crash too) locked its UI. However, the client code has a limited scope; the editor developers can and will fix bugs there, in contrast with dozens of exotic language support libraries in dozens of different languages.
Probably we could think of better editor design (isolate the core and let the other things crash — like in Xi editor, or something Acme-like with most tooling being external), but we already have a lot of editors. It is also definitely possible to design a better IPC protocol than JSON-RPC, but compared to the idea of isolating plugins (for me, it is one of the primary advantages of VSCode over any other editor with plugins I've used: it almost never crashes, and when it does, it preserves the state), and considering the resource-intensity of the language support itself, I think, JSON-RPC overhead is not as large as it looks.
Finally, I'd like to agree with the sibling comment: unfortunately, C FFI interface to a library is probably not easier to implement nowadays than JSON-RPC interface to a service in most languages, excluding C/C++, assembly and so Forth :)
Of course, an LSP client will also have bugs. When I tried LSP support in Kate editor last year, it crashed together with the language server. Emacs at some point (could be after a language server crash too) locked its UI. However, the client code has a limited scope; the editor developers can and will fix bugs there, in contrast with dozens of exotic language support libraries in dozens of different languages.
Probably we could think of better editor design (isolate the core and let the other things crash — like in Xi editor, or something Acme-like with most tooling being external), but we already have a lot of editors. It is also definitely possible to design a better IPC protocol than JSON-RPC, but compared to the idea of isolating plugins (for me, it is one of the primary advantages of VSCode over any other editor with plugins I've used: it almost never crashes, and when it does, it preserves the state), and considering the resource-intensity of the language support itself, I think, JSON-RPC overhead is not as large as it looks.
Finally, I'd like to agree with the sibling comment: unfortunately, C FFI interface to a library is probably not easier to implement nowadays than JSON-RPC interface to a service in most languages, excluding C/C++, assembly and so Forth :)