But either way, grunts depend on the lifecycle of the product. You bring in grunts to run the plant once you've built it. When you are in the process of building the plant you have a lot of dev work you want experienced (domain & tech) seniors doing. Foundational decisions and implementations that come from having some scar tissue in the tech & domain. Throwing grunts at the problem early will just allow you to re-implement your previous mistakes in similar ways.
And yes Python doesn't feel like a great system building language, it will probably be tucked away into the same corner as Perl in a decade or so.
Throwing more lower-skilled people at a project just makes it move slower and reduces quality.
The median level of skill and conscientiousness (particularly) is just so low.
Which is to say - most of the stuff you expect a senior to just be able to do as part of their job while also writing better code.
A large enough org may be able to offload much of those tasks to dedicated people and/or teams. Similarly a mature enough platform could have lots of BAU dev that can go to grunts because the basic infrastructure already exists and the workflows are well known with good tooling.
So it really depends on organizational size & maturity if its a good trade.