Pair programming can be a useful tool on a team of software developers. Twice the brain power*, more eyes on one problem, more perspectives and greater opportunity for knowledge sharing.
However, I feel it's highly situational and it isn't something that can be forced broadly. Applying it so broadly reduces productivity, increases frustration in the team and can reduce the quality of output on certain kinds of tasks.
I think very traditional pair programming and the techniques applied can be beneficial and it should be available as a tool to teams, I'm not here to dismiss the practice, more-so challenge the dogmatic attitude to pair programming that can be found in some teams. Specifically, the attitudes which applies it broadly and which strictly applies techniques such as driver-navigator, ping-pong, etc.
In my experience, when asked to pair with someone - it's often fine and appropriate, but in many cases it hasn't been. In some cases I've been able to steer away my partner to an approach I think works better for many kinds of tasks.
I have found for certain kinds of tasks (identifying them relies on intuition, it's hard to create rules to classify this), it's more useful to have each developer work how they work most optimally as a developer, which often means: somewhat independent, at least in the mechanical sense.
Solving a puzzle requires concentration and focus, something that can be much harder to achieve when you're having to process through the thoughts and actions of your partner in a pair programming exercise too.
When approaching an open-ended task, one that requires investigation and understanding of a wider system before certain tasks can be completed, I've found a good approach to be one that has two people working on the same problem, but in a mostly independent way, to have them on their own computers - next to each other - to be utilising their own personal approaches for tackling problems. To investigate, experiment, prototype and to talk constantly about what they're finding and what/how they're doing it.
The idea is that you're allowing developers to utilise all their own best approaches for solving problems, they're not constrained by how someone else works and thinks about problems. You're allowing developers to get into and through the meat of the problem quicker with a better understanding, because they're allowed to use all the (mental) tools they know best, they're not trying to teach someone else to use their tools, they're not being guided on how to use someone else's either.
One developer may get to a milestone before the other, like an understanding of a certain component of a system, which can then be presented to the other - then you get their thoughts and understanding on that once you have transferred the knowledge you reached before them. You benefit from the other perspective, you bring your partner up to speed and then you go back to working towards the next milestone.
You share ideas and come to agreements on how code will be written, you present back your code and decide with which approach to go for, perhaps it'll be neither, perhaps you'll discover something new about the problem in the process of presenting your findings and approaches
I suppose my thoughts are that having two developers work on one problem is often very useful, but the methods in which many try to make this happen can be oppressive, frustrating and sometimes counter-productive. To allow developers the freedom to work in their own ways, whilst also benefiting from the extra perspective, the open dialogue and kind of 'brain storming' of findings and ideas, feels like an approach more suited for more of the situations developers find themselves in.