1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).
2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.
3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.
Of course, hindsight is 20/20 and all that.
Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.
And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.
Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.
All of those things would still have eaten some of Perl's lunch.
See, that's one of the things lots of people who enjoy Perl and/or Ruby in the comments around in this thread don't quite grasp: some languages require programmers possessing a somewhat special state of mind to read and write productively, and some languages allow pretty much every mediocre programmer to read and write, and still produce a manageable program.
The other thing is the information density. In my experience, most people after graduating high school have experience with reading mainstream fiction and school textbooks, and those things you can half-skim/half-read and still get out most of the meaning. Then those people hit the college-/university-level textbooks and screech and crash because those books, you have to read them sentence by sentence; not everyone can get get used to it (or even realize they have to do that in the first place). And similar observations hold for programming languages: Perl and APL are just way too dense compared to Go and Python; if you're used to reading code line-by-line (skimming over half of them), then it's really bloody annoying to switch to reading sigil-by-sigil (as for writing, well, we all know that typing speed was never really a bottleneck for programmers).
This lack of flexibility means that it's impossible to experiment with replacements for built-ins, and the lack of generics out of the gate meant so many things were simply impossible (like useful iterators).
Compare this to Rust, where almost everything like this is just a trait. If you want to offer a map replacement, you just implement the Index and IndexMut traits.
Overall, I don't think Perl is the best language design. It has some interesting ideas. Go is _also_ not the best language design. Is Rust the _best_? No, but it's better than both Perl and Go, IMO.
Many of us see that as an important feature, and a smaller set of people aren't too happy with the generics introduction for example. Or the recent iterators stuff they have added.
It makes codebases touched by a lot of people an absolute breeze to understand. There's no clever generic data structure/soup of traits/clever conditional types I have to understand from scratch. Everything is the same old boring maps and slices and for loops, nested sometimes. And functions mostly always return 2 values. There is no map/filter/anything. The name of function usually betrays the types. "getUserPreferencesBatch" is most likely a `func(userIDs []UserID) map[UserID]Preferences, error`. There's <1% chance it is anything else. People also tend to avoid relatively complicated datastructures like trees unless they are really really necessary. So you get boring, completely predictable, 70% optimal code.
Even when discussing implementation, people think in simple terms which leads to really simple implementations in the end across all team members. It basically makes drumming KISS into everyone really easy.
Now some people go all clean code or make functional wrappers and such, and that destroys all that's good in go.