I'm betting you haven't actually had to make decisions like this in a role where you were responsible for getting the most out of a limited set of resources. It doesn't even have to be commercial: even in well-funded non-profits that I worked with, maximizing the impact of your work is more important than maximizing the quality. If we were talking about shaving 5% off labor costs to put the extra trim on the shareholders' Lamborghinis, that's one thing. If good-enough quality will make triple the impact per grant dollar spent, the correct answer is pretty clear. If technical purity means the project isn't feasible with the allotted budget, it's even clearer. It's about how much you can do with the amount you have. Nobody who gives you money to promote childhood STEM education is going to care how much more technically correct your solution is if you run out of money before you can ship, and they certainly aren't going to give their new cancer-research grant a haircut because you wanted to save on end-users' ram usage. Using the existing giant labor pool of web developers to make an electron application isn't just
a little less resource intensive than making a Java application for nearly any purpose-- it's
vastly less resource intensive. That's just plain old reality. I'm not saying it's good, or worth praising; it's just the way our world works outside of volunteer-driven FOSS.
When I got paid by a nonprofit to work on MIT-Licensed FOSS full-time for years, these questions were as important as anywhere else where resources aren't free. If I had my choice, I'd have chosen Elixir and Phoenix to do many of our web projects because BEAM had built-in tools to solve a lot of the odd architectural problems we had. But if you suddenly had to hire a few Elixir developers to do something that would work fine with Node.js, just not as elegantly, that grant isn't going to get any bigger just because I'm making sound technical decisions. At the end of the day, your software is valuable for what it does for people-- not what it is.
And really, how much does using electron limit the actual utility of the tool itself among people with limited compute resources? I don't mean what's the difference in the memory footprint, I mean how often are people unable to solve their problem using an electron app because their computer can't run it? You obviously don't need bleeding edge hardware to run an electron application as hyperbolically suggested-- it's not much different from using, well, Chrome. Projects that work with really really under-resourced populations, such as the houseless, don't make desktop applications anyway-- one that I can think of off-the-top of my head used SMS because it was so much more readily available than a computer you can install an app on.
Developers like to focus on things like memory and compute resources because they know how to address them. Hammers looking for nails. But if you really dig into users' biggest frustrations with software, as I have in my interface design work, performance is almost never mentioned. When it is, they're almost exclusively dealing with shitty internet access, not slow local application execution. If FOSS projects wanted to do more good in the world rather than having a hobby project to nerd out about, they'd actively solicit designers to figure out what problems real users are actually running into trying to solve their problems rather than just assuming the solution is more technical correctness. They could be one of the few volunteer-driven FOSS projects isn't solely usable by people who already have a working mental model of software development.