Unfortunately I don't have much to add to the OP, but I wanted to comment on this. Everyone I know that hates Perl had some sort of experience where they inherited some legacy Perl script that broke all the time and yet performed business critical functions. I started my first full-time job in 2004, and whenever I get together with my old co-workers we'll STILL talk about the battle scars we had trying to bubble gum and tape together a particular script called cc_processing.pl (yep, just as critical as the name implies), that seemingly broke every other day and went so far down the rabbit hole you had no idea how it ever ran successfully. $a{$a} = $a->{$a}? Sure, why not.
I wonder how much of Perl's reputation is based on these kinds of formative experiences. I love Perl, but I'm realizing that everyone had their nemesis in sitecounts.pl, or traffic_reports.pl, or partnerpayments.pl, or wtf-how-did-this-ever-work.pl, and unfortunately didn't draw the same conclusions about Perl that I did.
I can tell you that people are still creating these monstrosities today, now more likely with Python than Perl in my experience. I saw one in particular in an academic research project, a true "kitchen sink" script that did all kinds of loosely related administrative things in a massive construction of argument parsing and if-then blocks.
For me the problem with Perl isn't the language but the mindset the goes with it.
It's like it triggers some primitive release of testosterone which results in developers competing to fit the most functionality in one regex filled line of craziness. Hilarious to watch. Hell to debug.
Massive perl scripts that still lurk in our memories of the 90s were not the result of testosterone fueled one-up-manship brogrammer culture. They are the result of needing-to-get-the-report-generated-yesterday one-man-in-the-"computers"-department every-programmer-was-a-sysadmin and-every-sysadmin-knew-perl4-because-that's-all-that-shipped-with-HP-UX/Solaris/AIX (and you had to pay extra for the compiler to build something more modern) culture -- if a single person working in isolation can define a "culture", that is.
It's scripts like these that spawned the meme of replacing people with scripts; because that's what these massive scripts did: automated away entire departments, or negated the need to hire for a department all together. Which is important when you're a two man company and all of a sudden you've discovered you need to process $100k of credit card transactions from yesterday, and you better get started on it because there's already another $300k in transactions generated today. It's only one script, so there's no need for revision control. Damn, there's only one guy working on it, it can run out of his home directory. And of course, it was so successful, successfully a blackbox, he's asked to automate some other task, which is only related because there's some slight dependency, and, well, it's a dependency, so let's just put it in the same script we already run. Rinse, repeat.
Were these scripts terrible? Of course. But they were the work horses of the Internet and any company with two CPUs to rub together in the 90s. There's a reason that "perl is the duct tape of the Internet" was a saying in the mid- to late- 90s: because it was.
These scripts work perfectly fine if the person who wrote them and fully understand them runs them, yet inexplicably fall apart when someone who didn't write them run them (similar to [0]). These scripts can smell the fear of the new guy put in charge to maintain them. This is where heisenbugs roost and schroedinbugs become the stuff nightmares are made of, despite that they had most likely been running without issue for months or years since the guy who wrote them left.
Don't blame the language either. It just is what it is. But there is value in the things you can learn about the code, the people, and the times by taking an anthropological view of it.
In fifteen or twenty years we'll be reading rants from people who had to cut their teeth on some overly designed, needlessly abstracted, difficult-to-build-all the-dependencies-for rails app.
Along those lines, reading Programming Perl is a pleasure in good part because Larry et al. spend time explaining not just the language but also where some of it comes from and its rationale (or not so rational ;-).
Note that I'm referring to the first or second edition (maybe the third); I understand that the fourth edition is just recently out.
If folks have enough programming experience with other languages, it's easy to write Perl that looks more like those other languages, but unfortunately the moment a developer gets overworked or wants to show off (opposite extremes, really), Perl can devolve faster than some other languages because so many tricks are possible when vigilance is not maintained.
I've had decent success with making one-class-per-file with MooseX::Declare and Method::Signatures::Simple, but you really have to have a good code review process and rock solid developers to make it happen.
I don't think it's the languages fault, as this can happen just as quick in (say) Ruby code, and you can write extremely bad code in any language. Those other languages tend to be slightly faster to develop in though, as you can forget all of the need to write things like "my" and the reference syntax. Things like Python and Java have some resistance to "having fun with syntax games", but fall into other traps where interesting syntax (or architecture games) become fun or quick shortcuts.
On one end, part of Perl's problem is not Perl at all, just that it was historically the first thing people learned after Bash, and often those folks really didn't learn to program yet. On the other end, it is easy to go crazy with it.
Incidentally, the same mindset goes with pretty much every other programming language I've seen. The long regexes exist because a short one was "debugged" and "enhanced" into the long one. The same goes with full programs; that five line Java class is now 1000 because all of the bugs were fixed and features were added. You can't blame Perl for the programmer that won't way "we're not shipping that feature today, we're going to split this regex into its own module."
(There is also a skill level issue; regexes are much easier to understand than parser generators, so a lot of people try to implement a parser with regexes.)
I wonder how much of Perl's reputation is based on these kinds of formative experiences. I love Perl, but I'm realizing that everyone had their nemesis in sitecounts.pl, or traffic_reports.pl, or partnerpayments.pl, or wtf-how-did-this-ever-work.pl, and unfortunately didn't draw the same conclusions about Perl that I did.