Pair Programming is difficult.
It's difficult because it works best when the 2 people involved are close in skill level and that can be difficult in some work environments. It can be more difficult when you swap out because you need to find someone else with the appropriate skill level and then bring them up to speed on the current problem. The benefit is more people have exposure to any given piece of code that has been paired on. This should lead fewer times where code can't get fixed because no one knows enough about it. It should also propagate group ownership and the ability for anyone to pick up any piece of work.
I have found that even in environments where pairing is done, pair swapping is not worth the cost. However, this may be due to our tasks never taking more than ~1.5 days. We found a great benefit to breaking tasks down to be no bigger than ~1.5 days worth of work. Pair swapping may make more sense in the context of longer running tasks.
Partly, it depends on how you are doing pair programming. In some instances, the driver of the pair is writing code, while the second member of the pair is observing and discussing the design and implementation details of the system. Another instance of pair programming involves both people writing code simultaneously - one person is writing the implemented functionality and the other is actively developing and writing test code at the unit and integration level, again discussing the design and implementation details of the system.
Regardless of the type of pair programming, it effectively serves as a continuous code review. You have two people's eyes on the code, watching for errors before they escape into a later system/acceptance testing environment or the field. You also have two people who understand a particular part of the system very well, to serve as a redundancy to minimize your bus factor. Both catching defects early and spreading system knowledge around the team reduces the cost of building a system.
The spreading of knowledge isn't just limited to the technical knowledge of the team, either. Depending on who the pair is, it can allow for information to flow between a more senior member of the company to a new member about other things that transcend the project - coding style, company culture, expectations, and so on. It can also allow someone who is more familiar with a technology or tool to share their knowledge in that technology or tool in a real-world applied setting.
As you mentioned, it also does help keep developers focused and in flow. In addition to flow, many individuals are less likely to interrupt multiple people working on something than a single individual working on something. If you walk by someone's desk and they are working alone, but you need to talk to them, you might knock and talk to them. This is less likely if you see two or more people collaboratively working or having a discussion - you won't interrupt them. Interruptions cost time, and spending more time means higher costs. It's in the best interests of the business to maximize productivity of the employees.
However, there are some challenges that must be overcome to make pair programming viable. Consider things like personality clashes or choosing the pairs to properly distribute the knowledge. There's also consideration of exactly when to rotate pairs. Pair programming done haphazardly probably won't be effective as one that's planned out. Depending on the makeup of your team, it might not be effective to pair people at all.
Best Answer
Research compiled by Laurie Williams indicates that pair programming works best on industrial teams when
In my personal experience I've found that my XP team spends about 60% of our development time pair programming on average. The remainder of the time is spent doing individual development. It is not uncommon to pair up to create an initial design, work alone on the design for a few hours, then come back together to finish tricky or difficult parts of the code.
I've also found that pair programming is most effective in approximately 1.5 to 2.5 hour blocks. Anything much less tends to require too much overhead to setup while much more and the pairs tend to get cranky and tired. Cranky and tired means you're not communicating well and might be letting defects slip into the system.