Perl was, in its day, a breath of fresh air. It had an emphasis on practicality that made easy things very easy: regex literals, default arguments like $_, minimal syntax overhead, with things that would be syntax in other languages hoisted to interpreter args (-e, that arg that means "run this as an awk-style loop"), and so on. More than that, the project worked as a holistic ecosystem, rather than just a language and some tools: these days every language has something like CPAN, but it was a huge innovation at the time. Perl also pioneered a lot of the unit-testing infrastructure that we take for granted these days; every project in CPAN was expected to have tests, using the same libraries, and they ran as part of the install process. A cynic might say that perl innovated here out of necessity; lacking static typing and not having VM isolation means good unit tests are a necessity. But still, the resulting infrastructure is very good, and some very solid programs are written in perl. In many ways I'd say it was the go of its day.

The downside of the emphasis on practicality was that the language always suffered from incoherence; with no principled foundation it's been slow to adapt as the practical things users want to do change (e.g. I'd argue string manipulation is a lot less important than it used to be - if you were writing perl today, you might give json manipulation the same prominence as regexes). Perl 6 may have been an effort to fix this, but went too far in the opposite direction; overly formalized, with a premature separation between VM and language that massively slowed development.

There's a lot of good stuff about modern perl - Moose and the like - but IMO it's too little, too late; other languages have been able to improve their infrastructure to (mostly) match perl for easy things. Meanwhile perl's incoherence makes it very hard to write large programs and solve hard problems, where languages with a firmer theoretical foundation and stronger stylistic principles have a huge advantage.