2. There are category issues here. Sam and Paul tend to e focused on early stage start-ups -- often you have one employee on a platform and you need them to have solo-ownership of that technology stack -- you simply can't train someone because you don't have someone senior to them on that stack. As you get larger, the cost-benefit of changing changes, but it's still important to take on training in manageable sizes: many companies are hiring 30 engineers with 4 junior positions -- maybe they can get that to 8/30 but I think if you inject too much inexperience in a culture you get too many problems in the code base. Some of the biggest bottlenecks to hiring juniors are other engineers: no one wants to do excessive overtime as a salaried work because they are training someone -- anyone who has on-call time wants to be confident it's going to be rare that they are responding to crisis and this tends to result in not wanting to put out fires from certain categories of mistakes.
The other issue is that for training to generate a good return on spend for company, employees need to stick around, and furthermore if their value was negative or less than salary during the training they need to stick around at below market rate for their current skills. Good juniors tend to grow at incredible rates, justifying $20K/year but it's hard for companies to effectively budget and act to retain these people.
The net result of high turnover and environments that are poor for training is to bias towards seniority: it seems a bit backwards to fix this by restricting talent so aggressively that start-ups are forced to hire more junior people -- they already have significant risk without having inexperienced people solo entire platforms.