I have this conversation literally every single time I join a team. (I am tech lead and/or manager and it is usually my responsibility to shape the development process).
People are definitely NOT taking twice as much time per-person to write a piece of code.
First of all, code review is already a cost tacked onto development to ensure quality. So one could say code reviews are a waste of time. Well... not necessarily. It is always cheaper to catch and fix an error closer to the source of the error. When the error happens in prod it may be costing your company millions, but the same error caught in review may mean a cost of somebody's 1h review and half a day to fix it and then re-review it.
So we are saying: it is better to spend a bit of extra effort upfront than let those quality problems spew uncontrolled into codebase and production environment.
Naively, pair programming means one person writes the code and another "watches" and catches errors. But that's not what is happening. People discuss the course of action so you usually already get better result with two people doing it. Then there is the fact that if one person would get stuck it is usually much faster to get unstuck with another person involved.
And you get other effects, too. For example, I find it impossible to procrastinate when working in pair with another person. It would be just disrespectful to the other person to be wasting time while we are both assigned and expected to produce results.
All this means that not only the quality is better than if one person worked on it, but also the work progresses much faster.
I would also suggest that in many businesses the most important factor is not development efficiency per se, but how fast can you deliver a given result. Meaning, if business figures out they want capability X, how fast you can provide it.
To get to X you create a project with tasks. Any project will have critical path and adding more resources to the project will not speed up the project at all. The only way to speed up the project is to either change the critical path to a shorter one or speed up the tasks on critical path.
There is normally very few ways to speed up development tasks. You can reassign them to your best/fastest devs. You can produce more technical debt. That's about it.
So working in pairs offers an invaluable ability to speed up the development process without creating more technical debt and without using your critical resources.
And yet another effect is scaling your development operations. Normally, adding more developers to the project creates more efficiency. Twice larger development team will not be twice more efficient. Working in pairs counteracts this problem a bit, ie. it lets the team be twice as large at the same level of efficiency/complexity. Any techniques that let you stave off the effects of growing organisation are very valuable.