Perl's decline was cultural

It does if you restrict flexibility, but one of the critical flaws in Perl culture was the belief in letting everyone evolve in different directions while cooperating. It’s a genuinely charming belief, but it’s also explicitly incompatible with ‘interchangeable parts’ employment, and tends to only work in an environment where every individual is the ‘wizard’ lord of their personal domain over code. Even if you managed to train everyone to parse Perl, the cognitive overhead of having to train everyone in each other’s syntactic decisions was O(2^n) expensive, which contrasted quite sharply with Python moving that expensive cognitive overhead to the Proposals system while the produced language had slow version updates and “What we argued about so you don’t have to retread the same ground at work every quarter” mission briefs.

Some of the reasons why I never bothered with Perl was that I had the perception that it, like Ruby, encouraged mutating and modifying classes on the fly, willy-nilly. And the lack of static typing. Python also did not have static typing (it has some optional typing now or something like it), but my perception was that monkeypatching was not abused as much in Python as it might be in Perl and Ruby. Not that I used Python a lot.

Perk was never much interested in fiat-enforced restrictions. That was considered to be the domain of local policy in a given project or team and not something to declare upon its users. We’ve since determined in programming that restrictions can exceed the value of perfect freedom (cf. Rust, TypeScript vs. C, Perl). But for scenarios where rapid flexibility is key (eg. ops eng, sans sre/k8s/etc) the flexibility is more important than the restrictions. Always have an adjustable wrench alongside your fixed-jaws, just in case.

Regarding restrictions vs. perfect freedom, I think it's also about trade-offs, implementation quality, etc. Typescript has very easy and well-defined escape hatches. Conversely, Rust's escape hatches are an active research field, not well-defined, considered significantly difficult by prominent Rust figures, the safety is leaky (for instance no_std), etc.

C is also a significantly stricter language in some ways than Perl, due to its static type system, despite that type system being primitive. C, ironically, is in some ways way stricter than Rust, since it has a goal of simplicity in its language, and thus writing compilers for it (despite its ancient syntax) and standardizing it is much easier than for Rust. And those properties are rather good for a systems language. Simplicity in the language does of course not generally necessarily translate to simplicity in the code, the ability to create good abstractions is worth a lot.

Rust has also experimented with editions. And there is the issue of Rust allowing backwards compatibility to be broken regarding type inference AFAI recall, in part leading to the 1.80 time crate debacle.

One can say the same for C++.

Yup. An explicit 'sane' subset of C++ can trivially linted and enforced. Sadly, the same can not be said for Perl.