Amen. There are a number of reasons not to do code reviews:

- time constraints - both total resourcing and latency (Do I really want to tack on more unscheduled time when I am already working nights and weekends? And: If this bug is so pressing and people are waiting on it, does it really need to sit there waiting for two days for suggestions about how we should rename all those variables and filenames?)
- sense of ownership - parts of programming are personal; how you choose names, how you structure methods, etc. pp. Having someone with a radically different opinion chime in on all of your code distances you from professional pride
- reduction in accountability - if it's my code an my code alone that I check in, I am on spot for anything wrong with it. Submitting it to a large amount of group think absolves me from responsibility more than is good for the quality of the codebase
- standardization to the lowest common denominator - holding all of an organizations code to a standard risks replacing excellence with compliance. Rarely is the average you can get everyone to agree on the best possible solution for all problems

My suggestion is to allow anyone to make changes to any code while being completely responsible for the consequences. You can always review any checkin after the fact (that's what source code history is for) and change whatever you don't like. Just be sure that if I end up spending a day merging with your renaming of my variables, it'll show up in my weekly report and my manager might ask your manager questions about the business value of what you do.