I work at a company that does full-time pair programming whenever possible. There can be drawbacks for sure, but overall, I love it. However, one caveat is that our hiring process places emphasis on finding people that are collaborative and easy to work with as opposed to know-it-all "rockstar" developers. We also do test-driven development, so in addition to the most common pattern (driver / navigator) we sometimes do it a different way wherein one person writes the failing test, then their pair writes the implementation to get the test to pass along with the next failing test. Rinse, repeat.

I generally find the axiom "If you want to go fast, go alone. If you want to go far, go together." applicable to this context.

----

Benefits of pair programming (IMHO):

* It eliminates the need for code review (most of the time) since another dev is providing input as you write.

* Pairing senior and junior developers is an excellent way to build the abilities and confidence of the latter.

* Pairing decreases siloing of knowledge and one individual's "ownership" of a particular feature or system. You much less frequently see things like "Oh, you have a question about our Widget Framework? Go ask Sally, she's the only one who touches that part of the code."

* You're less likely to implement hacky solutions just to get something to work because someone else is working alongside you. (At least, I am.)

* It's easier to find and fix bugs (in my personal experience) when you have two sets of eyes on the code.

* You have to slow down and explain your ideas before immediately jumping in and implementing them. I generally find that reaching consensus with my pair about the strategy to solve a problem helps surface edge cases I might not have thought of alone.