I would go so far as to say it is a best practice. It aligns incentives. If you know you're going to have to wake up at 2am when your code blows up, you are more likely to make it resilient.
Isn't it also true that a developer who routinely misses sleep, is less productive and makes more mistakes during working hours?
But I have heard your argument before, and it kind of rings hollow. Unless you are willing to allow developers to push changes to production in the middle of the night and without supervision, what exactly is the benefit of having them on-call? Saving money?
Your point is correct thought that the responder does need the ability to make a hot fix. Non actionable alerts are of negative value to the company.
You should read The Phoenix Project, that will help you understand the rationale.
What makes you think I haven't read it? When my company went through its so called "devops transformation", first thing our devops advocate did was giving away a dozen or so copies.
I understand the rationale. I just happen to not agree with it.
In my mind, it's naive to believe that a team would have more than two or three competent coders, with a thorough knowledge of the code base, the high level vision of where that code fits and interacts with the rest of the infrastructure, the skills to quickly fix things, and, on top of that, the willing to be on-call several days a month.
And then there is the fact that nobody looks for solutions at 2am, just workarounds.
How many at a time? It has to be two or more, otherwise anyone could push changes to production at any time, without supervision.