Too many increases the chance that the other persons code is written with themes and idioms that the maintainer is not familiar with.

Why does your organization not have coding standards?

Why are you not performing code reviews of some kind?

Why are you hiring maintenance programmers without sufficient language experience or at least sufficient training in your organization's coding standards?

You betrayed your own argument when you said "poorly written code". How can you even identify code quality without these things?

If your maintenance programmers can't handle the style of syntax your organization uses, I can't see how they have any hope of handling the interesting problems of maintainability.

Not all your code is your own. In large organisations there can be multiple coding standards at work from internal and external organisations. What you suggest, isn't Perl specific and does not diminish the fact that Culture and syntax do play a part. If code readability is not a major part of the language design and syntax, then those coding standards are more likely to endorse stylistic elements that are difficult to read. If the culture of the users think obfuscation is cool then that too may slip by in code reviews by members of that culture. Perl code is maintainable. I, and many others have had to do it. It's just the language, and culture doesn't make it particularly easy. - Paddy.

It's just the language, and culture doesn't make it particularly easy
You provide no evidence (not even anecdotal evidence, just some innuendo) to support your claim.
• Language portion of your assertion is fairly easy to define, perl code.
• The Culture of a programming language is a little harder to define. I propose an applicable definition of "culture" in relation to a programming language: the sum total of ways built up by human beings and transmitted from an experienced group to an inexperienced group in a community. I think some acceptable examples of community would be Perlmonks.org and c.l.p.m.. I'm sure you come up with others. Since it far easier to (at least loosely) quantify experience at perlmonks.org I would suggest you start there (here). Saints in our Book should be a good marker of experience. Culture could then be quantified by the responses given by experienced members of a community to inexperienced.
• By 'it', in your claim, you mean 'maintainability'. Still hard to quantify but could be done. You could come up with a set of standards. Post an RFC and you would most likely get some good help.

It should be fairly easy to get a wealth of coding examples and answers from perlmonks. Then I would bet (a sixer of Rouge Dead Guy Ale, to be specific) if you examined this data and scored maintainability, you would find perl culture and language tends toward highly maintainable.

grep

If your maintenance programmers can't handle the style of syntax your organization uses ...

is it just me, or is that getting a little harder lately? finding maintenance programmers who are familiar with Perl's vast syntax, i mean.

I don't know; I'm not in the business of hiring programmers.

I do know that if you just throw code over the wall to programmers so junior that they get stuck with maintenance until they get promoted out of that swamp, you've increased the risk of failure on your project.

I suspect that finding good programmers and training them to work with your coding standards and problem domain will help. So will taking software maintenance seriously instead of treating it like diaper duty.