I think that only speaks for your own experience. I have definitely seen more than a few PRs that needed significant work.
I'm not sure how much I'd enjoy working on teams who were routinely producing PRs that were in bad shape.
When I was Bar Raising for promotions, I didn't review their PRs, I reviewed their Reviews. I reviewed the PRs that mentioned those reviews to see what slipped by. I looked at non-crunch time to verify they were reviewing at least as much code as their teammates.
If I saw someone 4x-ing the amount of code, they had better be 4x-ing the reviews too... if all they were leaving was stylistic formatting comments, they'd never make it to L6, unless the only thing they were reviewing was L6 code.
On your original claim, I have seen engineers put up 5x more PRs simply because they paid less attention to the quality or put less thought on each one of them.
I have seen people put up 5x more quality PRs too. But as long as they follow the good practice of doing a code review for every PR they put up (or 2 if you require 2 per PR), they got their stuff through quickly as well.
> your process ought to catch both of those well before the PR stage
We have multiple points where mistakes of any sort can be caught, and code review is one of them.
Yes, most architectural issues should be caught earlier, but some will only become evident in code: some by the dev themselves, others by reviewers.
This is only a problem if you mostly catch architecture issues at code review phase.
In this sense, I'm not sure I've ever seen a team that does codereview "right".
In the before times, most PR feedback was stylistic, with the occasional bug identified. Now that we have ubiquitous auto-formatters/linters/CI, most PR review falls into either "you misunderstood the spec", or "I disagree with your architectural choices" - and my personal feeling is that your process ought to catch both of those well before the PR stage