[bkz]

My view is that pair-programming is a tool which only really works for stuff dealing with tactical decision making, logic/fact checking, teaching or debugging.

Higher level abstract stuff which involves creativity (design) or strategic decisions won't work because there is no process for these activities. You can't synchronize (communicate) where you are on your way to the "eureka" moment. Discussing with others certainly helps but there nothing pair-programming specific about it.

Also, don't forget that most, if not all, of the assumed benefits of pair-programming can be gained using a more flexible common sense approach:

Reducing defects? Code-reviews.

Over engineering? Design documents.

New hires? People switching projects? Assign a mentor for a week or so and have them pair-program.

Faster debugging? Understand that it is OK to ask a colleague for help.

[sofuture]

I didn't even know people pair programmed full-time. It sounds... awful.

My idea of pair programming is a ~monthly "Hey coworker, you want to do sitdown this afternoon and figure out (in code) this bug/feature/design?"

Doing it fulltime sounds inflexible and impractical.