This glosses over availability a bit too quickly. You can't have high availability without at least dipping your toe into distributed systems. (BTW don't tell me about "single box" high availability or fault tolerant systems. I was there when they were created. They're distributed systems wrapped in tin, one with and one without extra circuitry to add complexity and cost.) A lot of people need high availability, including data availability, even if they don't need high scale.
There's a lot of jumping toward higher-than-necessary degrees of scalability, and lots of gatekeeping, but it's still true that for a lot of jobs "one beefy bare metal machine" thinking just won't allow you to meet requirements - with or without a backup that has to be promoted manually.
If you mention that companies can have HA requirements you get hit back with "most companies don't actually run a cost-benefit analysis for the complexity of introducing X 9s of uptime" or "most outages happen due to misconfigurations and human error, so your redundant architecture won't save you"
Not always. Rarely, in my experience. It seems like this crazy Manichaean battle because there really are kind of two different worlds - the mostly-desktop world where there genuinely might not be any availability requirement (data availability is "somebody else's problem") and the server world where there practically always is. People who only know one get on forums like this and act like the others are being irresponsible, and if they tried to do each other's jobs that might be true. But in the real world, people usually agree pretty quickly on which world they're in and act accordingly.
There's a lot of jumping toward higher-than-necessary degrees of scalability, and lots of gatekeeping, but it's still true that for a lot of jobs "one beefy bare metal machine" thinking just won't allow you to meet requirements - with or without a backup that has to be promoted manually.