Could they? I think they still have to prove they are able to deliver that kind of cadence at that price point. They aim to get there and I hope they do, but spaceflight being as fiendishly hard as it is, I wouldn't take their marketing claims as fact just yet.
Just because you can be lazy doesn't mean it's the best way.
Which one is "best"? Well depends if you are skills & money rich, or skills and money poor. Clearly both are best, depending on what you are optimizing for.
Up to now launches have been highly optimized for weight. Optimizing for other priorities (like cost) will change the rules of the game.
It does not. What it does not tolerate is mediocre level which seems to be taking over the world lately.
If you can remove areas of complexity then you are doing three things: 1. allowing mediocre people to accomplish the same goals as used to take skilled programmers, largely by throwing hardware at the problem (this seems to be the source of your complaint) 2. letting skilled programmers accomplish the same task in less time (again by throwing hardware at the problem) 3. making even more complicated things possible for skilled programmers
I certainly see the value in your complaint about things like the Slack app using Electron to make the UI easy to build (at the cost of my hardware performance), but that is a business optimizing for costs, rather than trying to optimize more for quality. Please assign the blame where it belongs.
It just forces you to be aware of certain things that are tremendously wasteful of memory and cycles, but which don't matter on "modern" hardware.
And by "don't matter" I mean "do matter a whole bunch, but your particular contribution to the problem is likely to be small enough that it won't help much if you spend the time to do it right, so why bother"
The software, or the service? Because IRC is not typically associated with tremendous reliab...*
* User has quit due to excess flood
OP's assertions it was more reliable are assuming a very static network. Modern protocols (Slack included) are far, far more reliable on a highly-unreliable transport layer.
That would actually be a pretty decent solution if it could be automated on a mobile device: run the IRC client in the cloud and then have tmux auto-reestablish every time it gets its connection dropped while the mobile device moves around.
I'd have to see it in action to be confident that a continuously-dropping-and-reestablishing tmux won't drop incoming messages or double-send though.
There is a happy medium between using Unity and hand tuning every line of assembly.
At this price points this low for mass to orbit it starts being reasonable to forgo technologies like super light materials, and reclaiming every molecule of water you bring up. You can build payloads for super cheap in a conventional terrestrial fashion and ignore the weight.