The problem with Perl is not just the time to learn it. The biggest problem is that Perl developers believe in TMTOWTDI (There is more than one way to do it) principle. As a result, numerous Perl idioms exist for doing the exact same thing. No matter how much time you spend reading Perl programming books and coding yourself, you keep running into idioms that look slicker and better (or just bizzare) relative to what you know.
Why is this bad? This is a difficulty for big application development projects where there are many developers working on the same code. The more expressive the language is, the harder it is for others to understand each others code. On the other hand, Python's inventor Guido van Rossum goes into great lengths to ensure that Python has one way for expressing a given task, and usually that it is the simplest of all alternatives. The result is a simple and tidy programming language that's easy to learn and understand.
Another problem with Perl is that it looks like an alien language for anyone who is not a unix wizard. At its core, the original idea of Perl was to have ONE language that combines the ideas of Unix shell programming, C, awk, grep, and other unix tools. To a unix wizard Perl makes total sense. To anyone who is not an expert in the unix environment, Perl looks like a gibberish. And even if they take time to learn what it means, they never understand the design decisions behind it without spending a good amount of time with unix and OS X command line tools.