The worst that can happen is that the company is down a few hours overnight. Issues can be investigated and fixed during office hours.
I'd wager that most companies don't have global customers and don't need 24/7 coverage.
I think this is a great example of why disagreements arise on HN: different world experiences and base assumptions. For many companies, being unavailable for that window of time would be catastrophic. We had one client that suffered about an hour of downtime (turned out to be their issue). They accounted that hour for 5 million dollars lost.
The whole "you build it you run it" movement is an attempt to fix dev teams just not giving a fuck about quality of code they put out, especially from a reliability point of view.
Why is the opposite better?
Probably this approach is more scalable specially in big companies where you can have operation teams on-call for a myriad of project.
I personally believe that this does not guarantee a better service.
It's exactly like properly/cleverly documenting your code/project: not only for others now or in a few year, but also for yourself later on.
It's having common rules across teams to get more reliability out of the whole company.
You build it, you run it. Fine. Until the point when you can't anymore (because... reasons - it just happens). In any activity you want to sustain, you always have to have backups (in people and in processes), instead on relying on your-(self/team) alone.
A whole business takes that into account as importantly as their disaster recovery processes (which is not necessarily something you focus early on, but you eventually do).