Especially in a large codebase where lots of different modules are technically in the same package as each other.
It's easier when a library author is publishing a small package for external consumption by other parties.
Another issue is that in Python any name in a module is implicitly available to be imported from other places.
For example let's say you have "A.py" inside of "A.py" you have "from something import foo". Now "B.py" can do something like "from A import foo".
So now "B" has a dependency that nobody really wanted to create.
Later "foo" may not be needed in "A.py" anymore and it will look like a totally unused import to anyone. Except it is being used by "B.py" too behind your back.
Someone deletes the "unused import" and something else somewhere else breaks because it can no longer import "foo" from "A".
(I have seen variations of this issue happen many many times so don't think I'm making some theoretical scenario.)
It's a very contrived scenario, and practically never happens if you use a python IDE. I've worked on multi-million line python codebases and this kind of stuff only happened when the (junior) dev insisted on using something like VSCode and not bothering to do a casual check of where they're importing something from. Also happened when you got "senior" devs with the idea of "python is just a silly little scripting language, I can pick it up in a weekend", but even then they were stubborn and didn't use a Python IDE, instead resorting to using a barebone and barely-configured installation of VSCode.
I'm not sure what use-case this serves, as all my library "don't be naughty" needs are handled by my IDE.
IMO it's unfortunate, especially because of that behaviour, that they're importable (explicitly) at all.