My team has done pair programming since its inception, long before I worked there, as part of a mostly "extreme programming"-style shop. Pair programming is the default state; people only really go singleton if there's an odd number, or occasionally for investigations, especially those which will involve messing around with hostile equipment and trying to get it to work.
"Junior/senior" isn't the only way to go. "Intermediate/junior" is useful; it helps the intermediate-level guy synthesize the knowledge he's obtained by forcing him to communicate it to someone else. "Intermediate/Intermediate" challenges two people work together to share their knowledge, communicate, and work as part of a team. And even if you have two really senior guys, chances are they have different areas of expertise and can come up with different approaches. The knowledge-sharing aspects don't end once someone's vaguely "up to speed" on a project. Rather, pair programming is the epitome of a learning organization. New techniques and best-practices spread rapidly.
Pair programming also helps maintain the quality of the code (fewer defects) and the sanity of the code (it doesn't just do what it intends to, but does what it should... ideally without going down a multi-week rabbit-hole doing the wrong thing, or two different right things that will conflict wildly). It helps the programmers maintain their focus: here in the heart of Silicon Valley, home of the 80-hour work-week, we can work for just 40 hours a week because we're doing intense coding for eight hours a day, switching things off with one another. (Also, if you went longer doing pair programming, you'd probably flip out. Or at least burn out.) This is great for work/life balance, and it also helps your organization when it's important to have fast turnaround (low-latency turnaround, in particular).
It's not all, completely, 100% peaches and cream; I find that pair programming is occasionally an obstacle to my application of intuitive brain processes which are useful on certain problems. Most recently, on a memory-leak task, I spent some time both with and without pairs; without one, I felt more free to mess around and try experiments without really knowing exactly how to explain what I was doing at any one moment. There are also some advantages in working singleton, being able to go off on a tangent and do certain wild refactorings (valued in the XP methodology) on a whim.
But all told, the benefits far outweigh the costs, and pairing has worked out spectacularly well for us: from the start-up stage through acquisition by a larger company, and our subsequent integration. (Speaking of which, pair programming has assisted us with maintaining a continuity of culture through expansion and despite a little turnover).
(We develop a software appliance in Perl, ~$4,000-$40,000 list price.)