The common pattern is that more senior devs generally end up handholding more junior devs throughout the whole process
First of all, pair programming does not inherently entail tutoring or mentoring. With a sufficient seniority imbalance, you have to accept that a chunk of the time is spent on training rather than working. This should already shift your expectations of immediate results.
If you want your pair programming to be completely focused on delivery, not learning, then you have to pair equal developers with equal experience, or as close to it as you can. You're not doing this, so you're inherently either going to hamstring your seniors (by having to go at the junior's pace) or needing to instruct the juniors about the work (since it's being done at a senior's pace).
basically coding while looking at a screenshare. "Scroll up", "Add a console statement", "Go to file X", "Can you write Y after line Z", etc.
That's not pair programming, that's dictating. It's both unproductive as a delivery mechanism (it takes two people to follow one train of thought) and as a learning tool (blindly copying as you're told does not foster understanding).
I would seriously reconsider the seniority of a developer if they are only able to focus on how to fix an issue and are not able to properly guide a junior developer. That is the distinguishing difference between a junior (can do the work but needs oversight), medior (can do their own work without much oversight) and senior profile (can do their own work and provide oversight for others).
Side conversations often come up during pairing sessions, distracting away from the work at hand
Non-work-related conversations would've happened if these two people sat adjacent without pair programming, and is therefore not relevant when judging that value of pair programming.
Work-related conversations are precisely the point of pair programming; it allows the pair to convey their knowledge to each other and/or helps them work together to learn something that's new to both of them.
Solving complex problems often takes much longer, because many engineers need heads down time to actually design a solution - doing so on a call takes longer and often results in analysis paralysis.
First of all, it's not called pair designing. You can't just arbitrarily lump these two together.
Secondly, pair programming does not entail that both sets of eyes are looking at the same thing at the same time, all the time, and nothing else. It's perfectly possible for the senior to do something else, whether it is looking at the next task's design, reading documentation, ... while the junior performs a more trivial task where the senior is either not needed or is able to juggle both activities at the same time.
The basis for your question comes across as a confused one. You implemented a system, structured it a particular way, and only then did you start noticing that the system doesn't actually help with the things that are seemingly important to you. That's putting the cart before the horse.
It makes more sense to first understand the problem you're trying to solve, then look for a system, confirm that it would indeed solve the problem, and only then start implementing it.