Many people in both engineering and managing positions see pair programming as basically, two engineers working on one problem and spending twice as much time to solve it, even though one could do it alone. I thought the same myself until some time ago.
While in some cases this assumption might be true, in other cases pair programming will actually save you tons of money.
Maintaining a complex codebase
When a codebase is very complex, often the problem is not to actually fix a bug, but to do it in the right way, according to the current architecture and while taking legacy decisions into account. In other words, finding the right place to put your changes is often a huge challenge — potentially a bigger one than fixing the actual problem.
One of the reasons our codebases become messier every day is because we fail to do that correctly. Pairing up with someone who has more overall knowledge about a particular codebase will speed up this process greatly.
Solving a complex problem
Sometimes a particular problem that needs a solution is so complex that a single mind will spend a disproportionate amount of time figuring out the solution on its own. Exchanging ideas between two people forces them to formalize their thoughts, making it likely they will find flaws in their thought process much faster and will boost each other's creativity in generating solutions.
There is a certain kind of knowledge you can’t really learn from reading stuff on the internet or in a book in a reasonable amount of time. Like, for example, a knowledge that is generated from working in a specific domain that represents years of thinking and researching, tactics for approaching certain problems in that domain or specific codebase, or techniques you could potentially google (but since you haven’t they’re probably not that easy to find unless you have the very specific experience).
In complex systems, we often find ourselves feeling less confident about a change, especially when we are new to the codebase. This makes us doubt every move and spend more time investigating alternatives. Working with an experienced person in the domain will inevitably boost developers’ confidence, as we will learn the thought process of a person who is comfortable working with that system.
Developing soft skills
Software engineers tend to be less socially and emotionally developed, due to the nature of working with computers most of the time. It is important that we go out of our comfort zones of talking to computers and improve our communication skills and emotional intelligence by exchanging information using a natural language.
Growing the team
There is nothing worse in modern engineering than a developer who is not gaining the right experience for the job. They will spend much more time finding solutions on their own in complex systems and they will develop themselves in different directions, without being able to sync, which will lead to more disagreement and less motivation.
Making engineers agree on a solution or technology and maintaining happiness are some of the hardest problems in growing teams. It is likely a bigger and more expensive problem than spending twice as much time on a task.