I believe the use of the word "fault" here means that there is nothing broken on the spacecraft, hardware or software. It behaved as it was supposed to, it was just fed a bad command sequence. i.e. any software fault was in the auditing software on the ground. Even then it may not be a "fault" (i.e. breakage) but just some conditions that aren't accounted for in the audit.
You have mistaken the role of government in healthcare. Government, by mandate of the people, already requires treatment of acutely ill individuals, and nobody is arguing to change that. The question is then how this is paid for (mandated insurance or socialized medicine), what is more cost-effective (in terms of preventative care), and is earlier treatment sufficiently more humane to be preferable in some cases? Also your "small minority of the population" is simply not small. A good 30-50% of Americans have trouble affording health care, partially because people like you prevent the appropriate management of the cost for the already existing basic universal health care. It's not all or nothing as you imply, a typical successful model is to provide basic coverage by mandate or required insurance, and then individuals with means can pay for other perks like shorter wait times or better rooms.
On the dental care side. If society places value on not having a bunch of snaggle-toothed people around, regardless of their ability to pay for orthodontic care, then the government can similarly intervene in that market on behalf of the public to make it more affordable.
Yes, same error, but you missed it. The fundamental problem is that truely secure non-centralized key verification is HARD. If the bank publishes their GPG key, why would you trust it?
Tools for managing one's trust network barely exist. This problem is not isolated to GPG. This problem is so difficult that the more commonly used protocols, HTTPS and S/MIME, solve it effectively by ignoring it and replacing it with a system in which individuals have little or no control over their trust network. Marlinspike has participated in efforts to improve the trust network for HTTPS, but makes the same error, as use of his tools requires one to trust him.
The case in the article seems like an example of this kind of problem with the systemd team. Instead of working with one of the prominent bootloaders to get the UEFI trust chain worked out, they just adopt an infrequently-updated nonstandard (sounds like = buggy) bootloader and run with it. This has the effect of abandoning all the work already put in by the prominent bootloaders to get corner cases working. It's a shortcut so systemd can add a bullet to their feature list, but provides the feature in such a way that it is buggy for many use cases.
I don't object so much to replacing sysv init, but the systemd team appears to have a tendency toward repeatedly reinventing the wheel badly just to get things done faster, and being kinda rude about it, and that makes one a bit uneasy. Though I'm honestly unsure if this is just the sensationalization of a few usual cases or more typical behavior.