Lots of great answers here. Some things I would add:
When you have to explain code to someone else, often in the course of the explanation the developer may suddenly realize he has a bug. I've seen it happen again and again that the dev stops dead in his tracks and says "oh wait that's wrong" before the reviewer has understood the thing well enough to see the bug.
Knowing your code will be inspected by someone else gives you more incentive to use coding standards (making maintenance easier) or use less "cowboy" methods that no one except yourself (and somtimes not even yourself) will ever understand. You don't want to be embarrassed when you show your code to someone else, so you do a better job on it in the first place. Because of the embarassment factor, it leaves less of the code commented with:
"I don't know why this works but don't mess with it." in the code base.
Developers who have the need for more extensive supervision or training are easily identified. So are the outright incompetent. The sooner you can find and address performance problems, the better off the team as a whole and the higher the quality of the application will be. It's good to find out this information before you take the new guy who needs training and assign him to the hardest, most critical part of your application.
Sometimes it is just a matter of correcting a misperception that will save making the same mistake in a bunch of other places. For instance we were recently reviewing some SQL for complex reports and found that several of our new devs had the same misundersatnding about where to find a specific piece of information in the database (admittedly the place they picked seemed logical which is a database design issue we also need to fix) that would be critical to correcly writing all the reports. By finding the problem and correcting it in the first reports they wrote, it saved the same error from happening in the rest of the reports. And something the older (in time working here not age) devs were so used to that they didn't think it needed explaining came out. It also made us realize there were some other things we probably neede to make sure the newer devs were up-to-speed on.
Juniors can learn from the more sophisticated code written by seniors (who tend to better understand error trapping and edge cases for instance) and seniors can learn from the new techniques used by juniors that they haven't been exposed to yet.
Sometimes people working on different but related parts of the application realize that they are going in two different and mutually exclusive directions. Ooops, easier to fix now.
It's not so easy to sneak in hard-coded values that will change over time just to get the thing to work now. This prevents a lot of future bugs such as things whih change at the beginning of each fiscal year.
I've sometimes been stuck on how to do something and learned a new technique that was just what I wanted from code reviewing someone else's stuff.
If you are familar with how the other members of your team think (which code review will help give you that understanding), then it will be easier to troubleshoot problems later because you will start with an understanding of how Joe would have approached that kind of problem.