Juniors will often be asked to maintain the code, it is critical that they can understand it.
At times juniors are the only people available to review the code of the senior developers. Should code wait to go to QA (we don't push anything out of dev without a code review and I am assuming this type of code review as well) because the senior's boss is on vacation?
I have also specifically asked juniors to code review something when I knew they would be doing something similar for a different client shortly or if I knew they had worked on something else that was similar or that they had a particular skill set.
If the code is fairly straightforward, I often get a junior person to do the review. Why waste the seniors person's time if the junior person is quite capable of doing the job? If juniors feel intimidated by reviewing senior's code, get them to look at the easier pieces initially. After all you cant get past being junior until you stop feeling intimidated.
I have often found that if I have to explain the code to a junior person who doesn't understand it, I will see an error I made (usually in an assumption) and that no experienced code reviewer would have caught because the code does run but doesn't do exactly what was intended. So just the act of explaining things will often help the developer see an issue without the code reviewer finding it. Since more experienced people are not often taken through the code step by step, these types of things are found more easily when a junior does the review.
I find that having junior involved in reviews has several good effects. First it makes them more confident when they can understand a senior person's code. It makes them even more confident when they can find a bug in that code.
It exposes them to thinking processes outside their own and lets them see other ways of handling things. Even as a senior person, this has happened to me - seeing a different way of solving a problem can be an eye opener to new possibilities.
It helps them learn to read other people's code and it gives them a chance to ask what the code is doing while it is still fresh in the minds of the author. That's a lot better than having to maintain the thing six months later when the author is long gone or is busy on another project and doesn't have time for questions.
It's good for the seniors because the questions both expose potential areas where the junior is weak and needs mentoring (so they can take more responsibility and give the seniors more time to do other types of tasks) or areas where the code is simply not clear to anyone except the author (which means it might not even be clear to the author a year from now when it needs to be changed). It also helps seniors realize that the juniors might be smarter than they have been giving them credit for being. It helps keep everyone on a professional footing. After all if you exclude juniors then you are clearly implying that you don't think they are capable of understanding the code which is psychologically unfortunate.
Juniors reviewing seniors code can generate more professional respect in your organization. Seniors may realize they have been underestimating the juniors and juniors may realize that the seniors do know more than they gave them credit for.
Juniors sometimes think they have greater skills than they have. Being exposed to code they can't write is good for these people because they start to realize they have much more to learn. It also will spur the best of them on to get the skills. In school sometimes the B students don't understand why they didn't get an A until someone shows them a sample of the A level of work. Same with juniors to seniors in code review.