It sounds like you are part of a pretty small business given that you're an engineer who knows his customers by name. It may very well be completely acceptable to your customers to have extended downtime, or a button that disappears during a deployment leading to a broken feature for a couple of days until you, or they, realize something is wrong.
Many other companies do not work this way. If you're a huge company like Apple that makes $40M per hour, that type of downtime isn't acceptable. If you're in finance, that downtime doesn't work. If you're in healthcare, defense, aerospace, etc... that downtime doesn't cut it. Yes, you'll still have downtime in those industries from a bad deploy, but you put more checks and balances in place to reduce the odds it will happen.
I'm not actually at a company where I know folks by name at this point. I was for a time.
I currently work at a much larger company where I ship platform-related stuff that integrates a bunch of systems (card payment processing... so fintech) for other developers so that they can ship features and products to customers. I've done a lot of the work mentioned in the article.
The hot-take is just a suspicion that we make things more difficult for ourselves by involving more people than is necessary to get work done, not trusting developers, etc.
Update: and is more a reflection about how the industry operates in general than how things operate where i work in particular
Many other companies do not work this way. If you're a huge company like Apple that makes $40M per hour, that type of downtime isn't acceptable. If you're in finance, that downtime doesn't work. If you're in healthcare, defense, aerospace, etc... that downtime doesn't cut it. Yes, you'll still have downtime in those industries from a bad deploy, but you put more checks and balances in place to reduce the odds it will happen.