Your experience is not universal. I paired for long enough to get comfortable with it. It never stopped stressing me out. I believe (and have years of performance reviews that suggest) I'm a very strong team member. But I work better asynchronously through text than synchronously through speech. It gives me time to get my thoughts in order before writing them down, rather than racing to simultaneously form thoughts and interject them into the flow of conversation.

I believe all of the benefits you list are real, but that pairing is not the only way, and in my opinion not the best way, to achieve them (with the exception of on-boarding junior employees). I have found architectural standards to be well served by a lightweight design documentation and review process. This has the advantage that the design artifact continues existing somewhere, rather than just being a communicated consensus between pairing partners. People can be kept honest in testing through good code review. I don't think the goal of code review is to make it fast. I think of a good code review as an asynchronous low pressure pairing session.

I'd like to just be happy for people to pair if they enjoy it, but sometimes it seems like advocates for pairing don't feel the same in the reverse. For instance, your reasonable seeming comment suggested that those of us who don't enjoy it so much are weak team members who should be weeded out during interviews.