It's hard for someone who was not the author to dive in to the middle of the code and understand it, debug it or upgrade it, due to the lack of explicit types.
Additionally there static analysis was limited to lint and refactoring tools didn't exist, or at least nobody seemed to use them (I never used PyCharm but I heard it can do some cool stuff).
Also for whatever reason these codebases often weren't very well structured and there was a common tendency to define configuration files that were themselves Python, resulting in the codebase spilling out into things that were theoretically just static data, complicating unit testing.
PyCharm is pretty neat, but coming form IntelliJ it's baby stuff. The tooling around Java can simply not be matched by a dynamic interpreted langauge. Probably ever.
And the more expressive your type system is, the more that becomes true. It will be interesting to see what is done for Idris tooling if it gets some popularity.
There's also lamdu[0] being made for Haskell which is pretty interesting.
Additionally there static analysis was limited to lint and refactoring tools didn't exist, or at least nobody seemed to use them (I never used PyCharm but I heard it can do some cool stuff).
Also for whatever reason these codebases often weren't very well structured and there was a common tendency to define configuration files that were themselves Python, resulting in the codebase spilling out into things that were theoretically just static data, complicating unit testing.