“Namespace” packages are not the default
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
If not every __init__.py file contains this, you run into the problem that you cannot nest while being disjoint: if you work for a big company, say, FooCorp, you cannot have the simple convention: “All our Python libraries are FooCorp.Something. Every product is FooCorp.<Product name>.” Otherwise, if one group in FooCorp violates the convention, and does not put __init__.py with the right magic, and they happen to be first on the PYTHONPATH, you’re SoL. Better learn how to hack your Python path.
Namespace packages behave weirdly in the face of sys.path changes
That, of course, is only a problem when you have to have your top-level namespace package in the thing that is recalculating the path. Argh.
Eggs, .pth and all that
Python has zipimports by default since 2.3. This means that the right way to package Python packages is “use zip”. The right way to “install” Python packages is “drop the zip file somewhere on your path”. No more. No less. If you need dependencies, some automated tool can help, sure. This fails if you have a PYD, of course, which is why PYD files should always be standalone and ideally, used only as a performance boost. For 95% of people, this should not be a concern anyway.
Every symbol is exported. The overhead on every single global variable that is not meant for export beginning with an “_” is too much. If the default was “__all__ is treated as  by default, oh and also the dot operator on a module checks in __all__ first”, people would have used __all__. When needing to fiddle directly with module content, people could still use the module’s __dict__ attribute (but then there was clear distinction between “using a module as intended” and “working around some issue in module”).
No standard naming convention
While at least the popular big projects usually just grab one node at the top and put their stuff under that, all the other poor schlebs tend to post their stuff all over their place. Especially for things which are often reimplemented, this is a mess — just look at all the modules wrapping postgres stuff. If we had a convention that the top-level is always “the organization originating this stuff”, then we could easily distinguish postgresql.wrapper from zope.pgwrapper from moshez.pgwrapper, without needing to remember a weird mapping.