All programmers have different levels of skill and experience. A CS grad just out of college may have experience with 3D graphics, but likely has little wisdom about the way coding happens. An expert at database coding may know next to nothing about web development.
Most organizations set building the skills of their programmers as a priority. Involving less-experienced or less-skilled programmers in the code review process can give those folks a better practical understanding of how things should and shouldn't work.
Code reviews have the expressed purpose of pointing out the flaws in the reviewee's work. This makes people defensive and nervous. Make a point of involving newbies in reviews of other people's code BEFORE reviews of their own. This gives them a sense of how things go and what defects reviewers will look for.
Code reviews have the expressed purpose of teaching newbies good techniques by letting them read the awesome work of their elders.
(Or at least that attitude leads to a better tack that helps correct the other stated problems...)
When my last company began CodeReviews, our first few reviews were of the code of an intern. It would have been brutal except that he was a good sport and we were pretty careful to review the code and not the coder. I would not recommend this practice (unless you practice hazing, which this would qualify as). We learned to MakeReviewsFun. -- JeremyCromwell
What would happen if you had the intern review the journeyman's code? Ideally, the intern asks, "why did you do THIS?" and the journeyman explains his reasoning behind it. This works well, so long as the reasoning isn't, "THAT's how we do things here."
Also see MakeReviewsConstructiveNotCaustic, CodeReviewPatterns, and BlackBeltsTrainWhiteBelts.