Now, as a reviewer your spidey sense tingles and you get the feeling there's a better way. But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this".
Pair programming would get you on the right track from the start. You are able to assist an inexperienced dev and guide them through the process step by step. Imbuing your knowledge, raising questions, suggesting fixes. This is exactly what the blog post describes. The developer was seen as unproductive because their time was spend pair programming rather than directly doing the work themselves.
I don't see how my post comes across as "I'm smarter than everyone". I know things that less experienced developers don't know, and that's a fact I know from talking to them and reviewing their code. But the culture just isn't there to be able to spend significant portions of my day effectively being their teacher (which I would love to do!). Instead it's often "the blind leading the blind" while the more senior members of the team are off delivering important projects and not having the capacity to imbue their knowledge onto the less experienced members of the team.
It's a culture thing and I wouldn't say it's a good environment for nurturing new staff. Spending 2 hours in a Teams call or at someone's desk is uncomfortable for both parties in a company that doesn't encourage this sort of collaboration. And so there's a sense to not "waste someone's time". The person you're helping sees themselves as a burden rather than seeing themselves as a student. And as a teacher, you're conscious of the other work you're supposed to deliver because it's not expected for you to be spending significant parts of your day pair programming.