At a feature level there are things like descriptors and metaclasses, which are complex and rarely-used.
There's a huge number of obscure magic methods/attributes: __origin__, __orig_bases__, __prepare__, __mro_entries__, etc.
It's full of gotchas: methods are looked up on the instance, except magic methods which are looked up on the class, except except __getattr__ and __dir__ on module types. There are both __getattr__ and __getattribute__ and they do different things. Most `typing.Foo` (and also modern `list[int]`) aren't `isinstance`-able. The use of += with tuples. The lack of any coherent numeric tower. Etc. etc.
I think it's very clear that Python has grown organically, and is now struggling under the weight of all its bolted-on extra bits, or sheer unnecessary complexity. I would love to throw it all out and start again.
Guido pushed back on most new features for a long time, but almost a decade ago changed his tune to yes for anything reasonably useful. Guessing due to envy of all the nifty features dropping from Ruby and JS to C# and Kotlin.
Personally, I'm not enthusiastic about the things that came after the f-string. (Although dict unions should have landed a decade prior.)
There are some valid points buried in this comment, but they are deeper than you perhaps intended or even know.
Metaclasses are widely used, but unless your specific problem calls for their use then you won’t use them. Usually these problems are related to authoring a library.
How would isinstance work with List[int]? Would it do O(n) isinstance calls on each element? Python isn’t typed like that, and a list is not and never will be an instance of List[int].
The magic method resolution order is also pretty natural and fits (slots?) nicely into the mental model you develop whilst using Python.
Does it mean Python is small? No. But that doesn’t make it big.