Depends on your day job
Most* programmers don't work on really interesting, exciting and clever things. Most* spend their time in banks and large enterprisey corporations "doing IT". In these situations pair programming works because the emphasis is (or should be) on quality, reliability and maintainability. Even if it takes a pair longer to implement some method than a lone hotshot Rockstar programmer, these benefits remains.
There appears to be some kind of snobbery among programmers** who consider themselves to be faster/better/more efficient/more clever then other developers. Their attitude (at least as I have experienced) is "Why should I share with you?" They miss the point that they're employed to write code that is quality and can be maintained by a _team_.
In some cases, e.g. contractors, the focus may instead just be "implement this as fast as you possibly can" in which case pair programming isn't the way to go.
Obviously intelligent decisions need to be made between "need it now" and "need it good". But to throw out pair programming just because "I can do it faster on my own" is just plain daft.
As an aside; Brennan's cybernetic principle is actually an argument FOR pair programming. Yes, if you have a plastic gear and a metal gear after time the plastic will start to degrade and get stuck to the teeth of the metal gear. But if the Senior Developer is modelled in plastic and the Junior is modelled in metal then you're effectivily saying that knowledge and (hopefully good) habits have been passed down the chain of experience. The analogy now fails because the Senior Developer still has those good habits and knowledge, whereas the plastic gear now has no teeth.
* I don't actually have any figures to back this number up, but it feels right.
** Note the difference between "programmer" and "developer"