A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes a huge monolithic monstrosity by creating their own ORM and object model with almost zero documentation in or out of the code and hoo boy, that is not going to be a fun time 10 years later when basically nothing has changed because no-one has the time or energy to parse out what they've "crafted".
Any time I've ever tried to look into <insert random open source C project>, I typically find the most esoteric and tersely named functions inhumanly imaginable. Variables like gt, pn, r8, _on, etc. I mean terse to a point of cruelty. And yet these projects often have hundreds of contributors who are happy to gloss over said unreadability, or at least forgive it more than Perl.
Oh, and you're fully expected to speak their argot fluently, of course, otherwise you're a castaway to be thrown stones at.
I agree. Perhaps Perl culture encouraged that kinds of development. But I've a seen number of monstrosities in other, better known languages that are "crafted" that way as well. I'm currently working with a large commercial product in C that would undoubtedly be easier for the 50-strong team of devs to work with if it was written in Perl (though they would still complain), and ironically it would probably run faster in Perl too (and be much more secure).
I don't think the problem is the language really, as Perl can be written in a modular and fairly clean way too (compared with many other languages) if the developers are minded to. I think it's the culture in which those large projects were developed. Or rather, the lack of software engineering culture for long-term maintanence, and a disinclination to use frameworks and patterns that would be familiar to new developers coming in later, especially from other environments. It may be that Perl's rise and fall was a product of its timing relative to software-at-scale culture as much as anything.
Despite its origins as a glue language, Perl 5 is a Lisp-like once you see past the syntax. Perhaps that's part of its problem: Lisp encourages creative and unique approaches to large projects too, and also isn't widely used any more.
Definitely you can keep your Perl under control with a strict(ish) culture but that tends to be the kind of culture Perl acolytes traditionally chafe against. I do somewhat blame the "there's more than one way to do it" Perl culture - that definitely encourages a, uh, "cowboy" approach to development that I've seen a lot in Perl houses (compared with, e.g., the Go houses that I now deal with because Go has a definite "one way to do it" culture.)
But yeah, pretty much any language can be twisted into a monstrosity if you let the devs run wild.
Maintaining that in house codebase that used it was such a pain. I had to help keep that ORM up to date with the new data models after the acquisition.