The pair is a collaboration. They develop together.
> Do you really need someone over your shoulder to make sure you can turn requirements into code?
I listed numerous advantages (and some disadvantages), none of which implied pairing was necessary. I'm merely answering OP's question on which environment has enabled my best work.
I'm not advocating pairing (I'm no longer in a pairing team), not even saying it's the environment that will enable the best work for other people. Our hiring process included a pair programming task to try to gauge how well that person would work in a pairing team, though it's also something you get better with in time.
I have no problem with collaboration - ie I’m working side by side war room style with one person doing the front end, the other doing the back end, the QA person testing, etc.
Do you really need to pair to write yet another software as a service CRUD app?
In particular, PRs and design sessions were/are a context switch which add friction. Even when pairing, however, we'd occasionally have team-wide design sessions, depending on the problem.