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.
