I'm glad this works better for them, or at least they feel that it does. I'd also bet that they're either a small minority of teams that jell so well that they manage to scale a codebase without it turning into a disgustingly inconsistent mess; or that indeed their codebase qualifies as such or is still too small for the effects to be very visible.

Code reviews are not a tool intended mainly to catch bugs. Types, automated tests and manual tests are going to do the bulk of your bug-catching after all. Code reviews' more relevant purpose is to act as QA for the code itself far more than it is to verify if the code achieves what it sets out to do. This is in service of both maintainability (which impacts your ability to make future changes and staff retention) as well as performance (by introducing the chance for another dev to detect suboptimal approaches).

Once your teams grow, code piles up, and static analysis can't cover all your bases, either your team corroborates the code that you write matches/defines group standards; or each developer's careful design accumulates as "organic growth" carefully duct taped together to barely work.

And just to state the obvious, code reviews are merely a tool to achieve this. Pair programming is another.