[flagged]
Personally I don't want to move my hands from where I'm writing to the other side of they keyboard just to move the cursor.
In the end, use whatever your feel most comfortable. I hate the VSCode interface and all of those notifications/popups and general slow interface, but I can understand who doesn't care or think that even with those VSCode is still more efficient for them. I also can completely understand the issue that folks say when they lost a long time tuning their Neovim configuration to their preferences, considering that I just have done so. But I still prefer neovim to VSCode nowadays, and not everyone needs to think the same, and this is fine.
They could have laid out the arrow keys WASD style. One up, one mid-down, two to the sides.
Nobody said they had to use dedicated arrow keys. Just lay them out like a normal human being. Whatever key for up should be up, whatever key for down should be down, whatever key for left should be to the left, whatever key for right should be to the right.
HUJK, for example. WASD is the standard example.
Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).
As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.
That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ).
Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.
The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.
Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.
For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.
Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.
The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.
(I wouldn't blame vim so much, but more the vim greybeards who think they're still using a 70's terminal)
HUJK instead of HJKL, basically WASD moved to the right :-)