I feel very strongly that being on call should be boring. We have very little tolerance for repeated alerts, or for alerts that aren't meaningful. If we see something happening a lot, we fix it or make plans to fix it.
Emergencies like, say, a database write primary going away on AWS, are things we can't schedule, but we can plan for them so coping with them is as unstressful as we can make it. We can also rehearse by doing replacements at unstressful moments. But the reality is that if everything explodes at 4am on a Tuesday morning when Europe is trying to get through its workday, I will be paged, and I will get out of bed, and I will join my team in fixing things. Not the whole team, because we'll keep as many people rested as we can. And anybody who's up with me fixing things will take the rest of the day off.
I once witnessed first-hand a SAN wipe disaster that was made an order of magnitude worse by sleep-deprived management making well-meaning but stupid decisions because they were sleep-deprived. I have tried to set up processes that will help us avoid this trap at npm.
I can't imagine a situation where we let somebody design a feature and nobody else knew how it worked. Code review ftw! Also design review up front. The reality is that some people are always more expert about some things than others, but we try to keep the "bus factor" for any single thing as high as possible. If you spread the knowledge, you spread the burden.
No Heros, Please.