Learning to code is all about writing it, or at least watching someone else write it. Therefore, I think it would help if he watched what you do on a screen (preferably in an IDE he prefers or is familiar with, even if you use something different), so he can see what the process of doing it better looks like. Let's discuss some examples:
Major issues in the logic
In other words, the code doesn't do what it should; it has a bug. Explain one to him, and how you spotted it, and what code would correct this. But how do you do all that? Well...
lack of knowledge for how to trace back an issue to the root cause
Related to the previous point, show him how you would diagnose and solve the above bug(s).
obscure naming conventions
Don't make this merely about saying, "we want things named this way". Show the best ways to change the names. The IDE makes that easier; depending on what it's set up to detect, it might also suggest or even automate certain changes. If you have such things setup but he doesn't, change that situation for him, or show him how to do it.
Note that this approach isn't just about bringing in intimidatingly long notes you wrote to say, "please remember all these rules". It's about showing him how to do what he's meant to do. It teaches the savoir-faire.
[I] didn't have enough time to discuss the "whys" for everything I was recommending & helping him with.
I think what I've suggested helps with this time issue too. I needn't tell someone with your experience how much the code can improve, before an onlooker's eyes, with a few minutes of these tricks. He might find it a pleasant surprise, though, depending on how many ropes he's been shown in the past few months.
He's very soft spoken & seems to take things to heart sometimes.
@PlayerOne's excellent answer highlighted the need for making "this needs to be improved like this" an impersonal observation. This is easily incorporated into the above strategy. The phrase "let me show you how to do it" will be more or less personal depending on how it's said, but the noblest spirit of what it's saying is the whole point of this exercise.
he's under a lot of scrutiny from our boss about his performance
If this is worrying him, it can motivate his agreeing to follow your demonstration. If you don't know he's worried about it, you needn't bring it up, or moderate the above approach based on it. I'm sure if you followed my suggestion you'd do it in a fear-mitigating way, anyway.
He doesn't seem to take good notes during reviews/trainings, and he also isn't very proactive about asking questions when he gets stuck on tasks. As such, I'm not so sure how much this code review will really "stick" in his brain.
That's a definite reason reading out your notes has a reduced chance of success, regardless of how mean or kind you are with it. I can't prove seeing it in action, as something that happens when we interact with the living, breathing beast that the code is, would work any better. But the idea that it would comports with my experience. Invite him to ask you to pause or slow down when he wants to write down something he chooses to think especially warrants it.
what else can I do to soften the blow when I go through the laundry list of the things he did wrong in the code?
You don't need a laundry list - not all in one session, anyway. The code he submitted's not quite right. That's fine: the code he had to work on in the first place wasn't quite right either, at least not for modern requirements. The fact you're starting from "his" code in this in-person demonstration is beside the point. It shows him how to address any code he encounters. You might need to do it more than once, depending on how many things he needs to pick up on; you can gauge, a few days after he's digested the first session, what would be mutually agreeable, given his and the team's needs. But teach him the key strategies, and the issues that arose this time will take care of themselves in the long run.
what are some methods to increase the impact of this training/review? ... I don't think he will succeed unless he really makes an effort to learn the best practices & methods that everyone else on the team uses.
I'll leave it to you to decide the extent to which you should invite him to "take the wheel" at moments you hope he can infer what to do based on an early part of the demonstration. Apart from that, I have one suggestion that's separate from the general premise of this answer: recommend a good guide for him to read (or watch, if you know of really good video material). One guide, for now, or maybe two or three very short ones. If it's a guide that helped you, further guides will have diminishing returns, so don't overload him, or seem like you might.
there is no option for automated code reviews before pushing the code to "production". This makes it harder to catch the types of issues I described above.
OK, time for one more idea. Tell him he can ask you to look at his code just before he submits it, to see what you think of it. If you can, make such code reviews, even if they require pulling a chair over instead of using something you can't have on this project, more common in the team. This isn't just about not singling him out. The last company I worked for felt all code should have two non-authors review it before a push. Maybe he could be one of two reviewers for someone's code, even your code! All of this should only be introduced gradually, of course, as he might not have the right abilities, or be confident in them, to be such a reviewer straightaway.