To make it work, you need developers who are true team players and recognize the future value of a good programmer. If your developers hate being bothered and think passing on knowledge to the younger generation, or think of it as pain, then you're pretty much already in a bad situation.

I've found that in these situations, the developers are always under the gun and suffering from a lack of time. I've also often found that they suffer from a dysfunctinal development process and several other self-defeating set-ups which suck up all of their time.

The time to teach other people anything isn't losing productivity since it should make both sides better. If you're just counting lines of code or time at the keyboard, you probably don't realize how much you're actually losing by creating information silos. If you can't come up with a way to effectively integrate a new person into your group, you'll be hurting when you lose key people (like I once did when he drove his sports car into a tree).

Every situation is different, so it's difficult to perscribe anything that works everywhere. Good developer docs (which means, not just the APIs, but how to use them), good task tracking, can help. Start new people off with small tasks, maybe related to wish list items or tool smithing, and gradually bring them up to speed on the whole project. Let them sit in meetings, etc. If you want a good programmer, you probably also want to keep them for a long time. A transition time of even several months sure pays off more than several short term bad programmers over the same time period. I've seen both situations.

The communication problem really isn't that bad. Give every new hire a sponsor: someone who you trust to be a good programmer (not necessarily the best), who can take the newbie under his wing for a while. Of course, this sponsor also has to have some skills at managing that, which a lot of programmers lack. Programmers, as employees, need to be more than just code slingers. A "senior programmer" who just slings code isn't really worth the title.

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.

I'm not sure about the "undue", but there will be pain. I think that's the cost you have to bear as an investment into finding/training good people.

The way I know (in a much larger work scale, but within small teams) is, that a person is joined to a project of limited time. It takes time and effort on part of the project lead/mentor to identify a task that is useful and reasonable to perform. You need a screening process or early-out if the person doesn't match your needs, or at least a way to reassign the person to where they can do less harm.

Setting up a "curriculum" to bring the person up to speed with "everything" is very important. I can imagine the following (which is how I started):

1. One week of assisted self-learning of the language. This means you need to provide study material that is good enough for your purposes and somewhat geared in the direction of the actual later application. For example, if you're going in the Tk direction, the PerlTk book might be appropriate, possibly together with a quick introduction to Perl. Other pointers to whatever resources you need should be provided, either up front or on demand.
2. After one week of "toying around" (which here also gets wasted by getting the email account, Windows account and various other permissions set up, so nobody can do much useful work within the first week anyway), the person should be ready to get a quick tour of your framework by looking over the shoulder of somebody else. "Framework" can mean a lot of things, from the distinction of dev/integration/production machines to the directory layout you use, to the program framework like Mason, Jifty or whatnot. The important parts of whatever you use to do the real work that aren't explained in any book.
3. Then, that person should be given a task at which they can work "at their own pace", that is, a non-critical task. The mentor will have to be available for questions and the task will have to be of the right scope, and maybe even introduce the person actively to some key concepts of your environment, but only these concepts that are well documented and obviously also well known to "everybody". This task is mostly to familiarize the new person with the environment so they don't have to ask about the totally trivial things.
4. That task should then be reviewed together, either at the end or at some milestones however you set them up. If you have a vast Java-ish class library or other opaque API which works with much magic, like a predefined workflow which is clear to everybody in the business, but opaque to anybody fresh, I think you'll need more milestones and/or some introduction into the business that relies on whatever software is programmed.
5. After that, the person should know enough of the framework/API to be pair programming with somebody who uses and knows the API without annoying them too much with their questions about the API.

This quickstart approach leaves out some programming key concepts that not everybody can learn within one week - for example, if your programming style heavily relies on closures and you get a C or Java programmer, it might be beyond them to get a quick grasp of how and why this works, so you need to prepare for that specifically in step 1.

A totally different approach or maybe accompanying approach is to give talks about your framework. That way, you prepare introductory material and also maybe attract people who like the mindset of your framework through the talk. But of course, you have to get people to come to your talk at all, so maybe you need to give those talks in a university setting, to attract people outside of your usual stomping grounds.