I was lucky enough to work in a serious PP company for two years, paired with ~10 people. I can appreciate PP when it's the right person, but when it's not, it can be downright unproductive.
A lot of software engineering practices like PP, TDD were preached like some kind of gospel but never stood the test of time.
However, pairing is great! Double so when one member is learning the ropes. Maybe one screen, maybe two. Give junior members the opportunity to drive so they get familiar in the code base. Maybe drawing boxes on a whiteboard. Asking questions. In short: _Collaborating_.
A good pair session doesn't have someone coding while someone just watches or instructs. It is truly collaborative. It could be a joint investigation or it can be a mentor/mentee situation. Generally, one person at a time on code branch, but not always. Maybe one person is knocking out something jointly understood while the other is following up on other things (documentation, asking other devs, prototypes, etc). It is a great way to share tooling, tips, tricks, code history, gain shared understanding, help destroy knowledge silos, and often two sets of eyes are better than one and can catch mistakes quickly when your own tunnel vision would have you wasting time debugging something in the wrong place.
I consider these types of practices to be similar to what you learned in school, like never start a sentence with "and", and other grammatical or format rules. As a novice, these rigid rules help. And then you grow up. You realize that you can bend and break all kinds of rules to achieve good results.
First and foremost, top tech companies encourage autonomy. It’s hard to achieve or support autonomy for an engineer if they become too reliant on pair programming. It’s also difficult to scale teams and projects if you need a well matched pair to execute on them. Good pairs are hard to find and harder to sustain. And a fair number of programmers like their independence and aren’t excited to pair all the time. For these folks, pairing can be a big tax.
And I have come across engineers who become individually far less effective without pairing, so it can become a crutch. And over time, it becomes really hard to continue setting them up for success. Their pairing partner might leave or simply lose interest in constantly carrying them.
There's also incentives for individual success that soloing goes along with. Whereas pairing might lead to a greater product solution and with the lack of clarity around individual contributions. From what I've seen that's why pairing is implemented at smaller places or on separate products that are run as more of a smaller company.
Background: I was at a company that was forced into pairing and xp and said the same things about me not wanting to do it and leaving if I had to. I then tried pairing out and absolutely loved it. I moved to a larger company, for unrelated reasons, where we didn't pair and did not enjoy it. So I came back to a company that does pairing every day and I can't imagine working in an environment that doesn't pair consistently again.
It probably sums up to 2-4h per month. I wouldn't want to have it be obligatory or mandated. We use it as a tool when we feel it's useful.