How else will they learn? I don't mean this in a snarky way, but what other options are there? Code review is _terrible_ for training. It happens at the worst possible time, when the only options left are rework. Micro reviews like this give them a chance to explain what they are doing and thinking, usually they figure out issues on their own this way. It's a chance to point out edge cases they haven't considered. Lots of times it's a chance for me to notice a gap in their training, like maybe they forgot that SQL migrations need to put into a file and committed, not just run locally in their database. Or maybe they are trying to edit an autogenerated file. Maybe they are building something that already exists because they didn't read through existing libraries. The list goes on and on.
The only other ways they can be trained is just by doing and making a huge mess, which is extremely inefficient. Plenty of Jr engineers will never become a Sr engineer without feedback and mentorship, they will just make messes, never improve, get frustrated, and leave the industry. Notice the recent SO survey showing how few devs we have with more than 7 years. I think total lack of training is a big part of this.
I don't want them to waste days building a feature totally wrong, then me spend hours writing up a "now do it this way", just to have them rewrite it all.
This isn't creative writing, this is engineering.
Better to make small nudges along the way, finding gaps in their knowledge, pointing out resources, articles, videos, and tools to get them up to speed. Then over time they get the satisfaction of needing less and less guidance, and being able to provide that guidance to others on the team.
Definitely it's possible for this to be oppressive. It's possible for this to be micromanaging. I think the same is true for the style of go away for a week, come back and I'll point out a week's worth of mistakes all at once now that you think you're done. Having done both styles, I think this is far less wasteful and is much more humane.
The way I look at it is this, if I'm the code/architecture quality gatekeeper, I want to give feedback as early and often as possible. Imagine you could only run unit tests after you've written all the code. That would be infuriating. I want to run them all the time, knowing very clearly what still needs to be done to finish a project. This is me providing that feedback about quality and architecture as early and often as possible.
All that said, I'm probably a lot more aggressive with the size and scope of a project I'll let a Jr dev take on. I've got one now doing a month long series of features that all build to one coherent epic. He's gaining more and more momentum and confidence, needing less and less guidance each day. There's not a change he'd get to build something this huge on a normal team, they'd reserve it for a Sr dev, but because he's able to figure out each day what needs to be done, he's able to build out something really quite impressive. He's written 100% of the code, made a majority of big decisions himself, and still I'm 100% happy with everything that is committed. The second he is done he'll merge into main.