My guess is people don't read warnings when they are a common occurrence.  A working Python should not emit any warnings, and a properly working Python program (post 2.6/3.1 (or whenever it was we decided to suppress deprecation warnings by default)) should not either.  But certainly messages that don't cause program termination *can* be ignored, and thus are more often than program-terminating errors :)

On the other hand, this *is* an error.  If we agree that python startup and site.py should not fail in the face of misconfigured libraries (and we aren't necessarily agreed on that :) then another option would be to use the logging facility to generate an error that would, by default, be logged to stderr but still allow Python to start.  That's not that much different from emitting a warning, functionally, but by having the message make it clear that it is an error it might make it more likely the user would take action.

As for whether or not we should want Python to be able to start up in the face of 3rd party library misconfiguration, I think there are arguments on both sides.  The most compelling argument I can think of for having errors in third partly libraries not cause startup failure is that a user borking their system python by installing a malfunctioning library would then cause all python-dependent system functions to fail to run until they'd fixed the install.  With a system such as gentoo where the package manager that the user might want to use to do the uninstall uses Python, this could be a problem.