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.
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.
[0] "Tom Knight and the Lisp Machine" http://catb.org/jargon/html/koans.html#id3141171
Don't blame the boy.
(And remember, he was raised by wolves. Yeoowww!)
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.
It's cyclical.
Note that I'm referring to the first or second edition (maybe the third); I understand that the fourth edition is just recently out.
TIMTOWTDI
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.
(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.)