For me, though, the showstopper that makes it impossible to use it as my primary editor is that editing files on remote hosts seems to require a zed server on the host rather than just relying on sftp.
That won't fly: I routinely edit files on hosts that zed does not support and on hosts that it does, but on an ad-hoc, now and then basis that does not justify installing the zed server. I need or at least want very much to be able to edit files on any remote host I can reach via ssh.
It's kind of a shame. Like I say, I think there's a lot to like about it, but for me, this really is a showstopper.
When the next paragraph says “the product underneath is Electron,” it is talking about the post-2014 wave of new code editors that built on Atom and then VS Code and then Cursor. JetBrains is the standing exception to that wave, not part of it.
Granted, Sun was so effective in their efforts to reduce the footprint of the Java VM, that it had dropped from the traditional two to four times overhead to only tens of percents more CPU and RAM resources, and their was no reason to beleive this wouldn't only improve, especially with coming hardware support for virtualization.
In the end what we got was Electron using tenfold the RAM that a native application would require, and IDEs so bloated they make FPGA development environments lean in comparison.
Do I misunderstand, or does the author start by saying that in fifteen years of using JetBrains IDEs, they haven't realised that they are not based on Electron?