Dev UX is important, and the dev UX of Electron is pretty much unmatched.
If you want people to not use Electron, you'll need to provide an alternative that makes it just as easy to develop sophisticated, platform-independent applications. Otherwise, no amount of complaining about Electron will ever stop devs from using Electron.
Dev UX is only good in that we regressed to the point that there's not much left but Web, and that's what the majority of devs know as a result. The Dev UX of the Web is pretty bad, though, compared to past and present alternatives, and I'm far from having as much fun putting together UXes for the Web as I was with older tech like Qt, Swing, JavaFX, etc (the tooling was better, more efficient, they had builders for rapid prototyping that were offering a more faithful representation of the design more quickly than figma ever will, etc).
I've used Qt, Swing and JavaFX, and found all of them absolutely terrible. Qt might have at least led to some good results, but it's fairly bad to use and deploy. Especially if you want to use the latest Graphics APIs, which worked pretty badly back when I last used Qt in 2016. I much prefer Electron, or imgui for C++. I'll happily sacrifice some features so long as I dont have to use Qt.
> Qt might have at least led to some good results
You seem to focus on the outcome while what interests me is the programming model. Say what you want about object-oriented programming, the problem-space lends itself very well to it. In Qt/Swing/… components are just classes whose behaviour and appearance are determined by function overrides, taking as parameter event or graphics objects. Just like that, you cleanly solve everything that "webcomponents" stands for: interface contracts are determined by class constructors/parameters, customisation is just class inheritance with member override, look&feel customisation is plain calls into the graphics API primitives, layouting/responsive-design is taken care of at the just level of abstraction, and all of it takes place in the same language and ecosystem/stdlib (no HTML to CSS to JS references to keep in sync and mental overhead).
React reproduces some of this model, but with much more technical and mental complexity, bringing trade-offs of its own. I'm not calling this easier to work with, simpler, or easier to debug. It certainly gives more creative options, but only because the ecosystem is broader (and full of supply-chain risks).
You sort of have a point, but users shouldn't have to pay the price for better UX for devs, the companies making operating systems should.
Even non-power users pay the cost, they just don't realize it yet.
But as long as users still need Apple/Microsoft/Google's platforms to be able to run Electron apps, those corps won't care, specially if it takes devs away from the toolchains controlled by them.
Maybe if someone can come up with a pure Electron OS that can run on any device, it might force Windows/Apple/Android to agree on a universal native UI API?
I'm not a dev (by profession). I don't care about the you-ecks of developers. Electron creates objectively terrible software by every metric that matters for the end user.
>sophisticated
You confuse complexity for sophistication.
Objectively wrong. Bad programmers create terrible software. Electron was used for some fantastic software like vscode.