Having proper knowledge bases and procedures, including how the ask "the team"/seniors "ad-hoc" questions and get feedback reasonable fast is what you want to have to solve that problems IMHO. Because that also tends to work if e.g. some people are sick or gone (knowledge bases) or can't come to the office (e.g. sick kids at home).
Through most important I would say is that communication in remote work is very different to office work and "just throwing slack into the mix" and doing the rest like before isn't going to cut it.
And yes that needs proper tooling, too and yes most of the tooling marked for this purpose today is .... pretty bad, sometimes utter garbage creating more work then they save time. Similar the part of procedures is often completely ignored, too.
If the oncalls don't have the knowledge to solve the issues they encounter, they need to escalate them and somebody needs to put more time in developing a more comprehensive knowledge base for them to reference, not just "steal" time from other company functions.
You are saying that people will be blamed for taking too much time to an example saying it would took 10h of someone's time instead of 5 minutes. Why the company will value more the deadline you are referring to than the time it takes for operations to solve the problem?
You are saying people should escalate. But on the example, the person who has the solution is the person you say should not be disturbed. So you are just asking to disturb uselessly people who cannot help, so your solution is even worse.
You are saying more time is needed to develop a more comprehensive knowledge base. But who should take the time to fill up the knowledge base if not the people who have the answers, which, in this example, is the people you say don't have time. (and moreover, funnily, those people complaining to be distracted are also very very often not doing any effort to share their knowledge somewhere accessible).
I'm slowly getting very irritated by the whole WFH debate: there is way too much arguments that boils down to "the problem is that _I_ am the one that people distract, so let's do my solution that is sooooo much smarter, let's do something where _I_ am happy even if it makes the situation worse for everyone else". That slowly creates this impression that a lot of pro-WFH are just little kids.
If you want to be metric driven, it's important that the processes be allowed to fail. Otherwise you are robbing Peter to pay Paul, and the KPI that looks BAD is not where the process is failing necessarily, but where the time got stolen from.
If you hire explicit 20% staff to do operational tasks, and also wall off a fixed rotating 5% of your dev team to assist them.. then you've made a conscious decision on resource allocation of 25%. If the other 95% of the dev team is getting interrupted every 30minutes by "questions" then your operational staff/rotation is not resulting in better runbooks, etc.
If you want better SLA and your operational staffing is not sufficient, then you should see your SLA breach, make staffing/process changes, etc.
When development just papers over these issues you end up with great operational metrics and bad development metrics, so then everyone can be even more upset at dev!
It's very easy to say "hey, can you share your screen" on a remote conversation. While in person that will require moving at minimum 2 people (often more) into a compressed setting with bad visibility at some random place of the building.