Earlier quoted context omitted.
I agree with your points, but the pair programming also has downsides, main one being that it doubles the total cost per task, and also it's usually limited to 2 pairs of eyes (again because of the cost), while code reviews can (and should) be done by as many members of the team as possible.
That “doubling of cost” thing is utter rubbish. If you produce higher quality code with two people deeply aware of the design and maintenance of a system doesn’t that reduce overall cost? I swear this “doubling cost” is one of those myths perpetuated by Taylorist managers. I’ve never seen any evidence to suggest pairing is less efficient overall.
It's not less efficient, but is it really 2x as efficient as having a single senior dev per task, with proper code reviews and tests in place? And it does cost double upfront, you can't avoid that and costs are the limiting factor for many (especially smaller) teams... some of this cost will pay back in terms of bugs being less likely and easier future maintenance and all that, but can you really claim that it will absolutely ALWAYS return the initial investment? To paraphrase on your own words: "I’ve never seen any evidence to suggest it's guaranteed to be that much more efficient".
IME (and I did a lot of pair programming in my career) it depends a lot on the people being paired, how complementary their way of thinking is, and also on the particular task being worked on. It will never produce a worse code than solo programming, that's for sure, so it's great if you can afford it, but if you can't there are other ways around it to come close (code reviews being one), and that was the whole point of my comment.