Pair programming is very known as efficient technique of writing code. Originally appeared as one of key XP practices, it got a lot of traction. You can find many publication about Pair Programming and seems everybody clearly understands it's value. Being a XP trainer and visiting conferences related to engineering practices I usually see such situation: the question goes to the crowd "How many of you do practice Pair Programming?" and I can give a bet, only few hands will appear.. very few people are actually practicing Pair Programming. Why?
Because Pair Programming is damn hard!
There could be 2 situations with PP: first one, then both guys are completely different levels of skills - it turns to be that one (more experienced) is writing and thinking all the time, another one is almost watcher helping to find a grammar errors in code comments. At the end of the day you got 2 mans powers producing 1 mans power work. Easy journey.
Second one is different, is then 2 guys are same or equally same level. Working in such pair could be compared to wresting. You literally have to fight to move on. All the time you under pressure of another man's opinion, usually strong one. You struggle much to get consensus on different topics. You are talking all the time and arguing all the time. Sure, you got shinny-working-super-cool results much more faster by working such pair.
But there is a problem - after 3-4 hours of working that way you will be completely exhausted. Believe me, you are absolutely useless after 4 hours session of true Pair Programming. Thinking, focusing, arguing, writing, testing, debugging over and over again. It takes a lot of energy. Working a 40 hours week in strong pair will let you feel like 80 hours week. There is also psychological side as well: 2 persons could not match each over, so working in pair would be like hell.
Pair programming takes double effort. You should not plan PP session for a whole day, half day as maximum. In my opinion it's not valuable to do every task in pair, simply it's not productive. Pick up most difficult ones, ones that requires cross-functional expertise or most risky ones. As problem well kick-started, rest of things might go in parallel. I really like Pair Programming, but I would not use it as day-to-day practice as XP suggests. Most of the time, it's more efficient to work alone.