As a completely biased user/person who is insane enough to adopt an editor as a lifestyle, I've been using a vim emulation layer for Emacs (Evil) and I've in a sense
gotten used to it.
That comes after dozens of hours twiddling around with configuration files that let you set leader-based keybindings and change pretty much every aspect of how the vim emulation behaves. And after using it for a while I've found it behaves pretty much exactly like vim, which in itself is a godsend in a plethora of vim emulation plugins that don't get everything quite right. Somehow it just works how you'd expect. If lsp-mode becomes stable enough we might live to see "IDE"-like features in Emacs being workable.
I wouldn't recommend this approach for everyone, though. Because most of Emacs was not designed to use vim emulation you often have to switch between plain Emacs and the vim layer really often, or even worse write entire keymaps for unsupported features. When you have to do this depends on the functionality you want to use, and this is variable enough that it's not possible to immediately get used to - you have to learn how everything works first and adapt your muscle memory/config to it.
Evil is also baked into Emacs, so you'd have to use Emacs with its 44 years of cruft and get used to its unique methodology to take advantage of it. People may either become disinterested in this or completely entranced by it (see: the author). Either way, you'd be spending time learning a lot of new editing paradigms instead of doing actual work.
Also Emacs is slow when opening and searching big files, and this stems from a fundamental decision about how Emacs stores open files in memory. In those cases I have no choice but to open a minimal vim to edit them.
In addressing the slowness problem the xi editor[1] is trying to move in the direction of never blocking the user's input and separating frontend/backend. However, last time I checked the JSON-RPC they were using was not performant enough for their needs. There was also a huge debate on how to do collaborative editing, and the problem they eventually stumbled upon was that in some cases you'd have no choice but to essentially do the same thing as git merge does to resolve editing conflicts. Also because the protocol is so generic people ended up creating dozens of frontends in several different languages that support different feature sets instead of combining all their effort into making an even better standardized client.
Text editors are at the same time universal and full of tough issues to solve. It is indeed a shame that the programs that are most capable of running programs lack good text editors, and vice versa. One time I got fed up with having to constantly use the mouse when using IntelliJ so I wrote an LSP server embedded as an extension so it could be controlled from emacs. Unfortunately I didn't have the time to constantly keep up with the internal APIs that broke every few weeks and fix all the edge cases.
[1] https://github.com/xi-editor/xi-editor