1. CPAN is awful. The website itself is so bad that the "correct" way to browse it is to use the big brother "Metacpan". Metacpan is also very bad, they strayed too close to CPAN design. Navigating it is a pain, and most of the documentation is done very poorly because no one puts time into formatting their readmes. None of the modules are in github, the issue tracker is a nightmare, the links make no sense ( "Source (raw) Browse (raw)" ) - the website itself is poorly done.
2. CPAN has many modules, which sounds like a selling point. The truth is that many of the modules we have worked with have bugs and poor documentation, and almost all of them are unmaintained. The owners either gave up or actually died (this is an old language after all). There is absolutely no support for trying to do common tasks with CPAN modules. You can't Google for your error, you won't get a response on StackOverflow. Bug reports don't get answered because the ecosystem is a ghost town. This makes trying to do common tasks painful.
3. CPAN is just messy all around. There's not even a command line flag to find out what version of a module you have installed. You have to hack into its internals to figure out what versions you're running. Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror. A "benefit" of CPAN is that modules are tested against multiple architectures for you. The reality is that these tests don't matter. The Perl developers I've worked with bypass the tests with CPAN by installing with --notest because it's faster, and more than once a module has failed to install because the tests failed. But the failure was either a false positive or had no noticeable impact on implementation, and there's no alternative and no one to respond to bug reports. The only known benefit of CPAN - automated test running, has never once proved helpful.
4. One point I like in this article is that Python makes the right thing obvious. Perl's "multiple ways to do things" is one of its bigger design flaws. It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex. It's all to the detriment of the language. I have to Google for how to iterate over a hash every time, because there's multiple ways to do it, and they all suck. I never know if iterating over a $hash is the same as iterating over a %hash or a \%hash. Or if I should be searching for "hash" or "hashref" or if I should be using a "list" or an "array" or a scalar or who cares. The multiple ways to do things only amounts to one asshole on the team will exploit some unknown feature of map to write shorter code, not document it, and no one can read it. Any efficiency gained from shorter code is lost to unmaintainability. Also, Perl is not efficient, so it doesn't matter.
5. The language itself is gross. Beauty is subjective, readable code is not. The prefixing of variable names with @, % et all makes dissecting code hard and Googling impossible. The tacking-on of modern functionality will slap you in the face repeatedly. See: references. References are one of, if not the, biggest design flaw in Perl. They were introduced as a tack-on to hack over it's shitty default data structures. They make reading and writing code confusing, overly complicated, and haven not once offered us any benefit. Perl's leaky abstraction over poorly implemented data structures is easily seen in references.
6. No really, the language is gross. It has magic built in, and the syntax is a nightmare. Everything is done with sigils (characters like ~!=@#$ etc). You get function arguments as @_ . You do a regex match with $string =~ /(capture)/. This will magically populate $1 through $n with capture groups. This is bad. To substitute a string, you do $string =~ s/a/b. This modifies the string in place. Try to Google for how to not modify the string in place. Seriously, try and Google for it. If you forget to include an even number of values in a list it becomes another data structure entirely. If you don't put a '1;' at the end of your module code it will fail to work (no, really).
7. Larry's personal beliefs stray into Perl too much. Larry is a well known Christian, and you must "bless" a reference, a keyword baked into the language. This creeps me out. It doesn't really matter, and I 100% acknowledge how judgmental I'm being, but it still is out of place in a programming language.
8. All of these reasons culminate to one point I just realized: Perl is a bad language for a team. It might be fine for one person to write code that will never have to be maintained or read to accomplish some dirty task. The "features" of Perl ruin it for a team environment. Feautres like its "flexibility", wheel reinventing to avoid buggy CPAN modules, unreadable features hidden in sigils, magic, poor documentation, and hacker culture make it a very poor choice for multiple people to work on the same thing.
This is the perspective of a relative newcomer (~3 months of Perl exploration). I'm not a Python advocate and I don't have a strong opinion of what other language you should use, but Perl has caused us many problems and we switched to Ruby early on because of them. Maybe if / when I learn more about it I'll have a different opinion of it. Right now though I agree with this article and seeing Perl go out the door is fine with me.