Benefits of pair programming

Team members work more closely to each other and don't feel isolated.
Reduces the total number of work-in-progress tasks on the project (Limit work-in-progress)
Accelerates the rate of task completion, with all Agile-ish benefits of that. However, this increase doesn’t fully compensate for the reduction of the total number of work-in-progress tasks, so the team throughput may be lower than if everybody on the team were programming solo. In mid- and long-term, however, shorter feedback loops (see “the smaller chance that people go in the wrong direction” below) and the learning effects make pair programming “faster” than solo programming.
Shared code ownership, bus factor = 2 (with no separate Code Review process required)
People broaden their experience, which will allow them to fix something in these areas or pick them up if the “specialist” in the area leaves the company, or there is an overload of tasks for this activity (idea from ‣).
Mutual learning, knowledge sharing: ways of working, thinking process, tips & tricks, useful programs, etc.
People in the pair counteract each other’s weaknesses and blind spots. (See ‣)
Accountability, maintaining focus on the task
Forces to plan the day, organize and break down tasks, thus the participants learn to do it better
The smaller chance that people go in the wrong direction: a person working alone doesn’t have as immediate feedback to their decisions
When facing challenges, the participants support each other to boost morale and persevere
Vast opportunity for mutual feedback and sharing vulnerability
When one person is distracted by some urgent task, the other one can continue working on the task, thus not losing momentum.
Pair work ensures that team operates with some capacity margin. Capacity margin is needed to resynchronise to maintain cadence (e. g., release schedule) or to consume excessive variability to avert consequences of very high queue states. (‣)

More generally, ‣.