I've always felt that one of the hallmarks of a good lead is someone who provides the additional training as needed during each development cycle. For me, that means I'm not only coding myself, or reviewing code, but sitting with more junior developers, pair programming with them to help them avoid the kind of land mines I've stepped on.
Mainly, I have no illusions that our primary goal is educational - it's not. Whether you're a senior, a lead, or a junior developer, the goal isn't your edification. The goal is always to deliver quality code to the customer. Preferably on time, on budget, doing what they want. I do recognize, however, that it's impossible for me to get all the work done myself, so it's incumbent on me as a lead to help everyone help the team succeed. And that means recognizing training opportunities when they appear in nature.
So, to your question about whether pull requests are the place for training juniors, I would have to say that it's not uncommon for teachable moments to arise during these. Hey, you're going to have to deal with your first merge conflict, let's go over that after the review. Oh look, you didn't include any unit tests for your DAO, we'll postpone your review until after we've had a chance to cover those new methods. Why did you think it would be better to use double primitives in this financial calculation than BigDecimals? Yeah, that's not really uncommon.
So, while I would say that it certainly can happen, but it's clearly not the main goal of a pull request. Nor do I feel there's an expectation that the code in a pull request is production ready. Often it isn't.
If you're using feature and release branches in a gitflow style branching strategy, then your pull requests become something more like release candidates. Not production ready, but something more approximating it. You know your code compiles (right) and you have sufficient test covfefe to make a decent claim that it meets the goals of the user story. And since you've already run several integration tests in your development environment, you have a great demo ready to go should you be asked to demonstrate your changes, which you will, during the review of your PR.
Ultimately, I feel that we should be providing assistance during reviews of the PR, but that assistance isn't around general coding. Instead, it's associated with preparing that proposed code for inclusion with a working base of production-quality code. The PR is an opportunity for developers to demonstrate they have a justification for, and a solid grasp of, each change they've included in the PR. And even then - even after we've weighed them down with unit tests, and demos, and loads of questions - there's still no expectation that the proposed changes are ready for production.
The code's close after all that. But then we let QA torture it.