Of course, we also had to adjust the way we work to make this feasible. For example, we discuss design and strategy decisions early and often, so that bad designs or obviously wrong choices generally don't make it as far as becoming a pull request, but are rejected already at the idea stage.
Then when we are uncertain, we make the pull request from very rough draft code, and expect to have the big ideas reworked slightly in collaboration with the reviewer, so that once the final pull request is submitted, it's largely in the shape we want, with only minor comments remaining.
----
The same thing goes for what you say about time pressure, really. We know why we have the review process in place, and we have hard evidence that it saves us a lot of time and effort in the end, so we don't circumvent it even under pressure.
And we, the software engineers, are the experts who understand this. Management might not always understand it, but that's their problem, not ours. If they start to throw their weight around, that's bad management. Also their problem, in the end.
And, since the cost of change [1] is so much lower at the idea and design stage, most things probably aren’t reaching PR stage that would be likely to seriously fail review (tweaks and details notwithstanding).
That's one of those software engineering facts that people spread as absolute truths that are far from absolute in practice.
It's mostly true, but requirements gathering can be a very expensive process too, and you can lower that cost with a working example. Also, UX designing can get off-track very easily if it's done in a vacuum.
Also related, for some problems, having your software tested before it's even written can bring a lot of productivity to the writing stage. (For some others, it will completely ruin everybody's productivity, so the idea that finding bugs at the "testing" stage is simply "more expensive" fails here too, you don't look at an unmitigated disaster and calls it "more expensive".) For some problems bugs in production are just consequence-free. And in way too many cases you simply can't design some valuable interaction without having people using your ideas on the wild.
TL.DR. that link is a very good rule of thumb, but beware of the exceptions.
for example Linus has to constantly monitor the current development of CPUs in the industry to be able to improve his kernel and keep it relevant, while leveraging and arguing for e.g. a radical change in direction or approach for the work he and his teammates might complete (again, to stay relevant and be able to complete meaningful/exciting work together).
Linux is the classical example of this. But many open source git projects work like this now. Commit access on an open source project is reserved for people in a gate keeper role. Usually these people are also contributing significant amounts of code. But the whole point of being open is that others can look at your code and modify it. And of course there is no obligation to merge those changes. You have to ask for those changes to be merged. And that request can be denied for all sorts of reasons. To get changes in, you have to negotiate with the gatekeeper and work by their rules.
Somehow this model never really caught on in the corporate world. They'll use git of course and they do pull requests even. But it's quite common for all people to have commit rights and have just a soft rule that pull requests ought to be reviewed and merged by someone else. But most companies and teams end up cutting corners when they are under time pressure or when management throws its weight around. Once a pull request has work done on it, it just becomes hard to reject it without creating a lot of internal conflict. Unlike the open source community where you have to negotiate with the repository owners to get your change accepted, corporate gatekeepers, if they exist at all, typically lack the independence that e.g. Linus Torvalds would have to accept/reject changes. They'll bow to management pressures, arbitrary dead lines, etc.
Gatekeepers like that are essential to large scale software open source projects. The short term interests of contributors are balanced with the long term interests of the software product. Companies seem to have a much harder time doing that. I think that especially large companies should be adopting this model.