Saying "my code is better than other teams' even without review" does not prove that reviews are not helpful - maybe if you get your code reviewed you'll ship even fewer bugs, and if other teams don't review they'll ship even more bugs.
Code reviews help maintain sanity in the code base, and are useful for sharing knowledge (both in terms of quality of code, and ensuring that there are at least 2 people who have some idea behind the code written). It provides an opportunity to have it read by someone who doesn’t share the same priors as you and helps you identify sections of code that may be confusing for another developer (including future you).
If Code review does lead to the identification of bugs that’s just a bonus.
There’s a reason Code review does not have a “run the code and test it” component to it and is entirely focused on code, and not whether it runs correctly.
But why delay the shipment of features/fixes to the customer for any of these reasons?
If code quality and human understanding is the actual rationale, it could make more sense to review code after it has shipped. In that way, it would cease to be a bottleneck for the developers or customers. Additionally, any bugs that appear in production could be accounted for during the refactoring process.
Saying that there is value to a practice is the easy part. We're forgetting to ask when to code review and whether or not code review should ever be a blocker to other processes.