Code to fix problems, even in theory, isn't unnecessary. Statistically, changes I did were very unlikely to produce bugs. I wrote about this in my post about why you shouldn't do code reviews: https://www.corbinstreehouse.com/blog/2018/01/code-reviews-p...
I worked for 5 years on a team who had just started using code reviews. What we found was that code reviews didn't often find bugs in the changes themselves, but they were very effective at preventing bad decisions that would cause bugs in the future.
There are lots of ways to make a change that gets the job done, and might even fix a bug, but can mean twice as much work to deal with in the future. These range from intentional but shortsighted hacks to simple mistakes by experienced engineers working in a large project.
You also mention style nits. I admit even I get annoyed by these. But bad style can make it harder for new hires to learn the codebase, which slows the team down. In rare cases, they can even result in bugs of their own like the infamous Apple "goto fail" bug.
Every team is different, but I can't imagine working on one without code reviews now.
I worked for 5 years on a team who had just started using code reviews. What we found was that code reviews didn't often find bugs in the changes themselves, but they were very effective at preventing bad decisions that would cause bugs in the future.
There are lots of ways to make a change that gets the job done, and might even fix a bug, but can mean twice as much work to deal with in the future. These range from intentional but shortsighted hacks to simple mistakes by experienced engineers working in a large project.
You also mention style nits. I admit even I get annoyed by these. But bad style can make it harder for new hires to learn the codebase, which slows the team down. In rare cases, they can even result in bugs of their own like the infamous Apple "goto fail" bug.
Every team is different, but I can't imagine working on one without code reviews now.