I've been mostly using emacs past 30 years ie. about the time when system memory wasn't any more constraint which while single user was about 8MB at least. But I did earn my living before that about 7 years mostly using vi as most usable editor in the system and that 8MB was luxury most of that time.
But even emacs IMHO was and is vastly superior, vi still had it niche fast small edits and especially before log based transactional filesystems. After power outage or bad brownout event system crash there was great chance you got to fixing filesystem with fsck (which did often take lot of time) and worst cases finally debugfs trying to fiddle bits that you get fsck fixing rest.
Bringing system up with old system could be tedious. Before you get system enough up single user mode and just root fs mounted you had to resort you way forward using those modest tools you had there. It was really great if vi did work, but it too required sometimes more memory than you had before swap was active. If not, then ed was your friend, ex is just vi without visual mode.
For a long time vi was also able to edit very large files. It did not require reading whole file in memory before it allowed editing as for example emacs did (or mmap's it memory later).
These days I use vi for quick edits like someone above mentioned and like it more than any later replacement (nano etc) if emacs is not there, not worth installing it for just quick change or when can't install on (embedded) or someone else's system for any reason.
Vi is often available also *bsd based appliances which I've been using like Junos, Netscalers, etc.
IDE vim support suffers from three problems. First, performance. I have yet to try an IDE that can match the responsiveness of vim. You can obviously tank vim’s performance with plugins, but you don’t have to. Second: clutter. Modern displays are gigantic, and yet most IDE users don’t have more than 40 lines of code on the screen at a time. The rest is occupied by a file picker, command palette, integrated terminal, LLM chat interface, and so forth. You have to go to some effort to reclaim those pixels; big context is not yours by default. Third: uncanny valley effect. Vim implementation is usually incomplete, especially when it comes to ex-style colon-prefixed commands. It’s jarring to run into a spot where your muscle memory doesn’t work.
In short, IDE vim support does not measure up to the experience of using the real thing.
vi is not available on modern systems, people are using clones like (neo)vim or Emacs with evil-mode. And those clones also have modern features too, pushing them to IDE-level of tooling. Proper IDEs are often still a tad superior in being an IDE, but their vi(m)-modes are very lacking in comparison. So at the end it comes down to where you set your focus, and often the vim-side wins over the IDE-side.
They are not meant to be modal, they do not implement Vim meaningfully, they just map a few keybinds. Extremely few have ever tackled trying to implement Ex.
Trying to map vim onto an IDE misses the point, as you'd want to remove most of the IDE getting in the way of actually sitting down and programming and getting shit done.
