For me, pairing helps avoid bad decisions before it's too late. There are a lot of choices in programming and when both I and my partner agree on a path it's probably the right one. If we can't agree, usually it's because neither is better than the other.
Also not all tasks are right for pairing. Research for example can be frustrating as a pair activity. This is another reason we like this setup since it gets out of the way for non-pair tasks.
1- Programmer buy-in (preferably grass-roots) rather than management dictate
2- Collective ownership of code
3- Frequent switching of pairing partners (switch multiple times per day)
4- Comfortable pairing stations with no "owner" so people can swap partners and desks easily
5- One shared workspace per project with good noise isolation from other projects
6- Office (or two) with a door for private conversations, phone calls, or when you just need to get away from it all
7- Personal space for each person for pictures, storage, checking email, etc.
8- Sensible working hours (pairing is tiring!)
9- Mature participants without major social hang-ups or hygiene issues
10- Mutual respect
11- Thought-provoking work (TDD & evolutionary design tend to make even boring work thought-provoking)
12- Four to eight weeks to get used to it
I like to think of knowledge as a resource with compound interest for the individual and especially for the company. Knowledge is built on what you already know and the more you learn the more ideas and knowledge you can generate. Teaching another is the key principle of pairing. If done correctly somebody should always be learning and teaching.