I like code reviews and think they can work. Here's some anecdotal evidence:
I work at a company where the "code review" is part of the process, but not all teams end up doing it (i.e. for time constraints). Specifically, there's a smallish team who mostly does not do them.
This has given me the opportunity to see the result of work done with "code review" and and work done without code reviews, by people in the working same environment, hired under the same (or similar) criteria.
In summary, there is a significant difference in code quality in the code written by these folks who usually skip the code reviews. Sometimes these guys work on code that's under my team's irresponsibility and we end up having to cleaning it up (to the point of rewrite).
If these people would do regular reviews, and talk about the code, and what makes it good or bad (this usually happens in a code review), their code would eventually improve. I know my code improved a lot by being reviewed by my colleagues.
The code review allows for some knowledge passing, and is also a quick "code readability" sanity test.
On the occasion that something is caught, it could also be caught at lower cost with other methods. Inspection is not as effective as testing so delaying testing for inspection is ignorant.
Its been publicized that the cost of correcting a bug goes up with time (i.e. its cheaper to fix a bug that is found in the development phase, than if it is found in the QA / testing phase; its cheaper to fix a bug found in QA, than a bug found by the client). I think I first read in the book "Code Complete".
Code quality issues are not caught up by the QA / testing people.
The worst code I have ever worked with has come at the job I've had for the last 8 months. It is all formally code reviewed and it clear that code review is the lowest value work that the programmers produce.
If your code reviews are not improving the code, maybe the process is not a good one. Maybe you want to share how you guys do it?