After a few years I discovered Sublime Text, with its tons of extensions and exceptional speed, bought a subscription and learned as much of it as possible, ditching TextMate.
Then I switched to Atom, mostly for the discoverability and the speed (back then) of development (and, frankly, for the hype). The only problem with Sublime Text, at least at the time, was the slow development process: new builds were few and far between.
I tried VS Code too soon, and wasn't impressed by how the navigation between buffers used to work (it has changed since then, I think).
A few years ago I did a serious attempt at learning Vim for good, but in the end I gave up, and I've come back to Emacs, this time to stay, unless something radically new is introduced.
The good thing is that I can usually tell my coworkers about features of the editors they use that they don't know, because I've used them a lot.
The only feature I miss from all other editors is the incredible speed of Sublime Text: to this day, if I ever have to edit an SQL dump (which I hope I will never ever have to do again), I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.
The odd thing about Emacs is that its vastly superior customizability (or malleabilty, as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.
I just tried opening a 1.1GB SQL dump in vim. It took 11 seconds or so to open. That was pretty slow, but after it opened, it was pretty fluid. I could jump to the end or the middle of the file in an instant and move around like it was nothing.
EDIT: I just grew it to 10GB, and though it took longer to open, vim still works fluidly after it does. Saving the file does take about a minute or two, though.
I was surprised to find that ex wasn't able to open the 1.1GB file. It returns an error actually saying that the file is too large. Since feedback is very minimal, I would have expected it to work by loading the file incrementally in a small buffer like less does without even worrying about the whole thing at the start (no displaying total number of lines, etc.).
ed was able to open the 1.1GB file, but not the 10G one. It returns an error saying that there is no space left on device. I imagine it refers to RAM. That's pretty disappointing.
You can try a custom sam(1) fork (it uses structural regex, google/ddg them): https://github.com/deadpixi/sam
sam -d for the classic cli mode.