The problem is on-call is an essential and critical part of a managerial role, but toxic to those in a developer role.
Managers must be on-call to ensure the appropriate people and resources are brought to bear on unexpected problems that threaten the business.
Developers must NOT be on-call to ensure appropriate attention is spent designing, developing and maintaining the code that makes the business possible.
The rise of software-as-a-service led to companies promoting "devops" engineering which conflates these roles and unfortunately helps unscrupulous executives unfairly squeeze more work from employees.
The core idea of devops, that managers/operators and developers should understand and be capable of performing each other's role, isn't a bad one. Those who understand how the business works at all levels can do more to make it successful. It goes hand-in-hand with continuous delivery.
The best engineers alternate between these roles in a predictable schedule. When in the managerial role they need to observe, react, delegate and escalate problems as appropriate. When in the development role they need to deliver features that create recurring value for the business.
But businesses should not expect engineers to play both roles at the same time!
This form of "on-call" is a toxic moral hazard. It's a sign of instabilty. It's a signal of executive grift looking for a quick pop. "on-call" robs developers of attention they need to develop the features and increases risks that schedules will slip.
It doesn't need to be this way. If a business needs software development it should hire or train engineers with that experience. Likewise if it needs managers or operators to deliver software as a service.
As an operator or manager I look forward to working a shift, but as a developer I will never again accept on-call rotation.