Perl spent almost 20 years with a new version looming over its head. It was known from the start that Perl 6 would be incompatible. This meant it always seemed to be a bad time to get into Perl. You were committing to having to do a partial re-write whenever Perl 6 happened to come.
As more time passed and the differences between 5 and 6 became bigger, companies that had been holding out for Perl 6 started to ask "If I'm going to have to do a re-write, why not re-write in something else?". Which is what we ended up doing.
I think there are various other warts in Perl compared to other languages in its niche, but I don't think they killed the language.
I think you are absolutely right. The warts only exacerbated the process you describe, because when potential new users checked out Perl and saw the warts, it seemed a lot easier to wait for the new version that was supposed to address many of them. So new users as well as existing users put off investing in Perl until the next version. In the early 2000s, it didn't make sense to learn Perl 5 unless you had an pressing need, because Perl 6 would be out soon and would have a much easier learning curve.
Perl 6 has to be one of the most destructive failures ever committed by the stewards of a popular programming language.
It feels like it almost did. There was a pretty frustrating couple of years there where it wasn't clear if 2.x or 3.x was going to be the winning version and the Python community seemed to have a lot of disagreement on that subject. My team invested heavily in alternatives like Node.js at the time to hedge against Python dying.
However, Python 3 did at least eventually have a reasonable backwards compatibility story which Perl 6 never really seemed to have. It's a bit harder to do now since Python 3 has marched on while Python 2 is formally unsupported now, but for a while in the 2.7/3.3 days, it was relatively straightforward--if a bit icky at times--to have a single code base that would support either version of Python, and many library and app developers took advantage of that to allow as-seamless-as-possible transitions, rather than the whole community having to immediately spend a ton of effort porting their entire code bases to an incompatible language. Mechanical code rewriting tools which were introduced during that period like 2to3 also helped ease the transition for many use cases and code bases, too.
The downside of all that is related: Since source compatibility was possible, the package distribution method remained the same, and at the same time for all the usual reasons, some useful packages never got updated with Python 3 compatibility changes. Today, there are still libraries in PyPI which can be pip installed with Python 3, but you can't actually use them because they never got the attention needed to be compatible with it. If the package is a pure Python code base, you might not even find out until you try to import the library or call a function, class, or method. Then you get to spend time in your favorite search engine trying to hunt down an alternative. Very annoying.
First, Python 3 wasn't intended to be a significantly different and superior language. It was always intended to be a one-time chance to fix warts and unfortunate decisions, not change the look of the language. For a beginner, the difference would look superficial, even though some of the changes were deep. One of the most fundamental, valuable, though ultimately troublesome changes was to change the string type from byte strings to Unicode strings, a change that to a beginner looks like a simple upgrade. You could start learning Python 2 and switch to Python 3 later at very little cost, or, as an experienced Python 2 programmer, you could feel at home writing Python 3 very quickly. You could also learn Python 3 and then go interview for a Python 2 job, because nobody would worry about your ability to adapt.
Second, Python 3 existed, which renders every other comparison hypothetical. For example, the Perl 6 project was supposed to deliver a language-agnostic runtime that would run Perl 5 code and allow it to be used by and used from Perl 6 code. Hypothetically, that might have been a superior way of providing continuity to the community than what Python 3 did, but we'll never know.
Perl spent almost 20 years with a new version looming over its head. It was known from the start that Perl 6 would be incompatible. This meant it always seemed to be a bad time to get into Perl. You were committing to having to do a partial re-write whenever Perl 6 happened to come.
As more time passed and the differences between 5 and 6 became bigger, companies that had been holding out for Perl 6 started to ask "If I'm going to have to do a re-write, why not re-write in something else?". Which is what we ended up doing.
I think there are various other warts in Perl compared to other languages in its niche, but I don't think they killed the language.