I found a 2008 meta-analysis. https://www.idi.ntnu.no/grupper/su/publ/ebse/R11-pairprog-hannay-ist09.pdf

From the conclusion:

Our meta-analysis suggests that pair programming is not uniformly beneficial or effective, that inter-study variance is high, and that perhaps publication bias is an issue. ... However, with respect to the central factors expertise and task complexity, the current state of knowledge suggest that pair programming is beneficial for achieving correctness on highly complex programming tasks. Pair programming may also have a time gain on simpler tasks. By cooperating, programmers may complete tasks and attain goals that would be difficult or impossible if they worked individually. Junior pair programmers, for example, seem able to achieve approximately the same level of correctness in about the same amount of time (duration) as senior individuals. However, the higher quality for complex tasks comes at a price of a considerably higher effort (cost), while the reduced completion time for the simpler tasks comes at a price of a noticeably lower quality.

By personal subjective experience, the usecase where pair programming shines most is onboarding and skill transfer. Basically, you have a person who needs to learn a skill and a person who has the skill, so you sit the person who has the skill next to the other person and get the other person to do a task that needs the skill by instruction of the person who has the skill. This is way more efficient than lectures and slightly more efficient than reading documentation, because all parts of the skill are taught, only relevant information is taught, and the instruction is necessarily in actionable form. Important conditions are that the learning person is open to instruction and correction, and the teaching person avoids meandering into irrelevant information. Pair programming done like this relies on both parties being effective communicators.

(A related technique is mob programming, which is useful for collaborative design assuming your code environment is highlevel enough to keep pace with the discussion.)

I don't think pair programming is ever *strictly* better than solo programming, but I have found it to be a great way to help teach skills that are hard to describe algorithmically:

Some specific cases:

• Debugging: when it comes to debugging, you can read books and watch youtube videos, but you get so much from sitting next to someone who has a good debugging loop.
• Performance & Optimization: great to watch how other people do this.
• Architecture: this is less about implementation and more thinking through medium-level architecture things. Specifically, picking the right abstractions and patterns.

A non-obvious one:

• Overcoming impostor syndrome: I did a Recurse Center batch a few years ago and pair programmed with someone who had >20 years experience, the majority at Google. He wrote half the standard library for a very well-known programming language. So I was pleasantly surprised when I found out that even he reads the docs and sometimes forgets how to do things in that language.
• Figuring out what's normal: I couldn't, for the life of me, figure out how to use kubernetes as a friendly part of my development workflow. I pair programmed with someone who was a professional K8s consultant, and asked them about persistent volumes for a postgres instance. I expected a "oh yeah, use this YAML setting" but actually got ¯\_(ツ)_/¯. So it felt good to know that I wasn't the only one who struggles with technology.

I found pair programming pretty useful when starting a new project from scratch, when changes are likely to be interdependent. It is then better to work with, let's say, 1.5x the performance of a single developer on one thing a time, than to work separately and then try to reconcile the changes. Knowledge transfer is also very important at this stage (you get more people with the same vision of the fundamentals).

This generalizes to other cases when there is a "narrow front" - when few things can be worked on in parallel without stepping on each other's toes.

Even more generally, it seems there are three kinds of clear benefits:

1) Less change synchronization (fewer changes worked on at the time).

2) Knowledge transfer (see @FeepingCreature's answer).

3) Immediate, detailed review - probably fewer defects.

There is also a matter of raw throughput (or how much time is required to make a specific change, while the rest of the code is assumed to stay the same, ignoring the cost of syncing with any changes done in parallel). A naive baseline is that a pair has a throughput of a single developer (since they're working on one change at a time). Fortunately, it can be way better, because one person can just focus on the details on the code and the other on the slightly bigger picture and next steps, look up the relevant facts from the documentation etc. This eliminates a lot of context switching and limits the number of things that each developer needs to keep in working memory. Also a lot of typos and other simple problems get caught immediately, so there is less debugging to do. It's not so clear, what all of this stuff adds up to.

I was able to find some studies about the topic, including a meta-analysis by Hannay et al. TL;DR: it depends on the situation, including how experienced are the developers and how complex is the task). It's clearly not a silver bullet and generally it still seems to be a trade-off between person-hours spent and the quality of the produced software.

I've had experiences ranging from "great" to "terrible" when pairing. It's worked best for me when I'm paired with someone whose skills are complementary to mine. Concretely: I'm very much about rigour, type-safety, correctness; the person I have in mind here is a wizard at intuiting algorithms. The combination worked extremely well: the pairer generated algorithms, and I (at the keyboard) cast them into safe/correct forms.

However, when paired with someone who eclipses me in almost every dimension, I ended up feeling a bit bad that I was simply slowing us down; and conversely I've also experienced pairing with someone who I didn't feel was adding much to the enterprise, and it felt like I was coding through treacle (because the thoughts had to flow out to another person, rather than into the compiler).

In my experience, good pairs are really good, but also quite rare. You're looking for a certain kind of compatibility.

To answer your actual question: just try it! It's cheap to try, and you can find out very quickly if a certain pairing is not for you. (I would certainly start the exercise by making sure both parties know that "this pair isn't working out" is not a judgement on either party.)