Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance.
Maybe text editors with an extensible feature set really are more complex than we've been led to believe?
Messy and simple are orthogonal characteristics. A terminal is simple in that cursor movement, colors and style are all the result of a bunch of escape sequences. Once you have a list of the escape sequences you want to parse or emit, implementing a terminal or an application targeting the terminal is not hard. It's messy because there are historically a bunch of different terminals that implement different escape sequences. It's not easy and it's not clean and beautiful, but it's still simple.
It's a bit weird to bring up scripting languages. The problem is that people want a customizable and scriptable editor. Solving that problem by providing a script language to its users is not overengineering, it's simply meeting a demand.
Looking at this, it uses some native facilities simply to setup a web browser view. Within that, it doesn't even use the built-in functionality of a browser to render the text you're editing, but resorts to custom rendering and layout using webgl. This isn't simple or clean. It's a convoluted waste of resources in that regard. Why not use one of the smaller cross-platform OpenGL wrappers?
Maybe it'll be a fine editor, but it's much more complex than it needs to be. I guess that because they set a "Web-compatible build artifact" as a goal on the roadmap, it makes sense, but is that really an interesting goal? What problems will be solved once the editor is a tab in Chrome?
On windows my current cygwin session with tmux and a single markdown document open in vim is about 25MB. Some of my chrome tabs (jira is the most complicated thing open) are nearing 200MB, somehow outlook is taking about 500MB and Visual Studio is eating many GB's.
Sublime Text and TextMate will both choke big time if you feed them a large enough file without any line breaks. I have some largish machine-generated (5-10 MB) JavaScript data files that will reliably bring either editor to its knees if I accidentally click on one of them. The XCode editor also chokes.
I seem to recall (though haven't tried it for a while) that the Visual Studio Code editor handles them okay.
It's not a big issue -- since these are machine-generated, it's not normally necessary to edit them by hand. Every once in a while, though, I'll accidentally click on one of them in the file tree. Then I'll curse and kill the editor process.
I even think it would be annoying if someone would just move cursor around when I edit something. And there definitely would be conflicts if they would try to edit the file at the same time. Who needs this feature?
See, I thought you were complaining about software complexity when you posted your original comment about "why does a text editor need so much abstraction". Nope, turns out it's just another run-of-the-mill anti-Electron rant.
Maybe text editors with an extensible feature set really are more complex than we've been led to believe?