Because the anti-types crew showed up and sabotaged it. Similar with perl and lua.
But languages with stronger and more intelligent leadership showed what's possible.
You cannot implement all the compiler optimizations for const and types in extensions. You need to fork it.
The problem is there are a lot of developers who have only coded with static typing and have no idea about the terrible drawbacks of static typing.
They don't understand what static typing does to code verbosity and development times.
Take Turborepo going from Go's typing light system (designed to emulate duck typing) to Rust's heavy typing system (true static typing). Originally the code was 20,000 lines and was coded by 1 developer in 3 months. When moved into the typing style you like so much, the same code is now 80,000 lines and was coded by a team of developers in 14 months.
Duck typing as done with python is the worst of both worlds. No optimizations, no enforcement. Just optional external typechecks.
Of course untyped code (ie runtime types in each var) is to write faster. You only need to add types to some vars or args, and gradually improve from there. Eg ints only, because they are optimized the easiest. No need to check for strings, bigint, floats,.... Or arrays to check for overflows at compile-time and restrict to ints or strings. Massive improvements possible, in size and runtime.
Or object fields. Hash lookups vs static offsets.
There are deeper optimizations that JITs can do such as knowing at runtime that the value of a variable is always 2 that typing information simply can't express.
Duck typed Python is optimal for development speeds, the only thing that matters in startup environments. It has it's niche.
You aren't gradually improving, you are gradually deteriorating the codebase to make it look more familar to you.