While I know the kind of environment that you're talking about, very little of what you say is rings true for where I work, and I suspect that most of it doesn't at many other good Perl shops.

We have none of the drawbacks that you mention. While we keep busy, the pace is relaxed. Our development process is working well. We document pretty well. (Several DBAs have mentioned to me that they have never seen a team of developers that documents so much!) Turnover is fairly low - in the last 5 years we have lost 3 programmers. (All three have worked in a series of startups, and moved on to yet another one. But to be fair, I expect turnover to increase in the future.) We certainly try to avoid creating "information silos". None of our programmers are just code monkeys. The will is not a problem.

The problem is that we recognize, individually and collectively, that adding a junior person would result in fewer projects out the door. And we don't really have that many projects that would be appropriate for a junior person. So when we add a person, we always choose to make it a very senior person.

We couldn't even give a junior person stupid HTML projects since we already have an HTML designer. (A very, very good one in fact - and he's learning Perl.)

As for the communication problem, I am not talking about not wanting to take the time for a junior person. Instead I am talking about the one that Brook names in The Mythical Man-Month. Which is that with n people there are n*(n-1)/2 possible lines of communication, which means at some point with a flat organization, adding a person can cost more time from other people than that person can contribute. (This isn't just true of human organizations, for instance it is why SMP doesn't scale to large numbers of CPUs.)

We are seeing this issue even though our team is small. Our solution has been to split off some people into specialized roles to cut down lines of communication. For instance that is why I mostly do reporting now. But still we are reluctant to add people unless they really carry their weight. And hence we always choose to hire people who are already good programmers. As a business choice, that is reasonable. I'm just concerned about how good it is long-term if every company does this.