Why do many programmers oppose pair programming?

1. For pair programming to work, you need 2 people who are not only good at development, but who are ok with watching those who aren't as efficient with keyboard shortcuts / development tricks take control. I know I suck at watching slower programmers wield the holy mouse and keyboard. I would just yawn away. Basically, it requires a lot of patience, and efficiency in using tools takes time to learn. So even if I teach a couple of useful shortcuts to my PPP, I cannot expect him/her to use it fast from thereon itself.
2. Some people like to figure things out properly before proceeding (me). Many people just like to get it the fuck over with. Such people WILL NOT BE ABLE TO WORK TOGETHER. When I do something, I not only want to do it properly, I also want to be able to do it faster and diligently the next time (preferably, without googling it again). Many people think that speed is the most important thing when doing some work. These are two schools of thought which work well in their own right, but which do not go together.
3. There are some situations where 2 options are equally good/ bad (e.g. naming conventions). There has to be a compromise. One person has to give up. If both people keep fighting for things like this, pair programming can be a nightmare.
4. Both people should have the same wavelength and should be able to have a light-hearted conversation every once in a while, while working(else you feel like you're working with a zombie).

Q: Why do many programmers oppose pair programming?
A: Because pair programming is too expensive in most cases for the benefit it provides.

The point of pair programming is to get feedback on the code you are typing from a co-pilot. Now, if the pair consists of a new guy typing and an experienced hand watching, it’s a decent way to get a new guy up to speed. But if both workers are experienced, there is not feedback all that often. The same result could be had for 10% the cost by code review.

Because Pair Programming™, as enforced by clueless managers looking for Agile buzzwords, is complete unadulterated garbage. It’s yet another case of “X is good, therefore, X taken to the extreme and enforced by the company rules must be better” (compare with TDD).

There is one and only one situation, where pair programming makes sense — knowledge transfer from the more knowledgeable person to the less knowledgeable person. Other than that, you have just wasted twice the development power for at best +20% benefit. Let me spell it out for you explicitly:

If both developers in the pair are of the same skill level, at any given moment one of them is almost certainly completely wasting their time.

Make no mistake, where I am working, we are a team. If there is a tough problem to solve, we will get together and throw around some ideas until one of them sticks. We regularly (almost daily) review each other’s code, especially when the work is still in progress (like Alan Mellor would say, “Code review on pull requests is most often already too late”). What we don’t do is have half of the team sit on their asses and twiddle their thumbs, while the other half is writing some routine code no one is bothered about.

I am about as excited about pair programming as David Gilmour would be excited about someone else plucking the strings while he were only doing fingering, and then switching places every once in a while. It’s about as efficient as having two separate internal combustion engines in a car.

Added on June 18, 2017: it has been brought to my attention that I was unnecessarily rude to Kent Beck in my last sentence, so I removed it. He is a good software developer, and it is likely that his idea of extreme programming fitted his circumstances at the time of the (in?)famous Chrysler project. I completely disagree with his assertion that it is the correct way though, and I would regard it as a good example of survivor bias (in other words, people who tried the same and failed completely didn't go on to write or edit tens of books about it).

Indeed, I don't think there even can be a one-size-fits-all solution to software development. Teams, clients, products, and tools all are different from case to case, and the process must be adjusted accordingly. Pair programming in particular only works for specific circumstances, which aren't encountered very often, yet some people treat it as a gospel because it Worked That One Time™. It is rather ironic, really, that extreme programming, a set of concepts revolving around flexibility, has become this calcified and rigid in a lot of people's minds.