I believe that you have largely answered your own question as to the relative benefits and drawbacks.
Code reviews can often end up being quite laborious and drawn out affairs, and anything that adds to the time taken to review code is going to make it seem worse. The way I see it, you want to keep your review process very short, and not labor too heavily over the finer points. So the key is to decide what it is about the review process that offers business value to your team.
Issues of style are probably one of the items I would place as the lowest of priorities. Sure, keeping code neat and uniformly formatted can make it easier to understand, but fussing over style can also result in HUGE inefficiencies during the coding process, because worrying about how pretty the code is takes the developers thoughts away from the problems to be solved. If you are still concerned about style issues, then using a Style/Formatting checking tool (E.g.: StyleCop for C#) is a great way to leave the style-specific issues to to last moment, and take the decision-making process relating to style out of the developers hands, freeing their thinking for the more important stuff. If you don't have such a product for your language of choice, perhaps a simple parser can be written to quickly scan your code for such issues, but this should only be done if you can see that real value will be delivered as a result.
Memory Leaks and other performance specific issues should never be up to the review process to pick out. Sure, if you spot something that will obviously cause a major problem you should point it out, but it shouldn't be the purpose of the code review to track down every little memory/performance problem in your code. That's what a good profiling tool is for, and they are certainly worth every penny spent if you manage to locate a very good one for the language you are developing in.
Logic issues are problematical at best, and these are the things that can really suck up a lot of valuable time when you are reviewing code. Rather than leaving this all entirely to the code review, this is what your unit tests should be used for. Yes, even tests can be wrong, however if you develop test first, Stick to the SRP and DRY principals, refactor mercilessly and define your unit tests as a means to to validate your specifications, you'll find that you'll end up with far fewer logic-related issues. If you test after you code, you're less likely to deal with potential logic problems as they arise, and more likely to forget to test a particular pathway through your code.
So if you do everything as I have suggested here, what does that leave you to do in the code review? The simple answer is that your code review becomes a fairly simple process whereby the coder explains to the reviewer how a particular requirement has been captured in the tests, and how those tests have been applied to the problems solved. You tend to spot check the code more, and analyze the tests more thoroughly, as this is where the greatest business value can be measured, and particularly when that code needs to be maintained later. To make the test code review even more painless, using a good Behaviour Driven test framework can simplify the review greatly, as the specifications are captured in code as an almost plain English description about how the test will run. Detailed checks are performed on any code supporting the tests, and if your BDD framework produces nice text reports listing the tests in plain text story/feature statements, then the process becomes even easier still. This all adds up to an extremely efficient process that will be just as valuable as a more traditional code review, but can be conducted much more quickly and in a more focused manner, helping you to avoid becoming bogged-down in trivialities and double-checks that often lead you nowhere. This leaner approach means more time spent testing and coding, and less time on administrative processes.
So what about those metrics then? If all problems are treated simply as "bugs", then the only metric you really need concern yourself with is the number of bugs you encounter before and after release, over time, and whether the bugs identified are trending in any particular direction. If you are using even a half decent issue tracking system, all of this information will be practically at your fingertips, and you won't need to worry about whether your review process needs to identify them. At the end of the day, your team wants to do what they are good at, which is writing software, and not spend too much time on administrative issues that often only offer something of interest to 1 or 2 individuals in the company. Even the most simple cost/benefit analysis would show you that time spent in red tape is going to drive your expenditure up and tie up resources that you could better allocate to new tasks, and this is probably where the risk and drawbacks will be if your code review process becomes too inefficient.
