I will be visiting this thread fairly often to keep up-to-date on what you all think. We on the Python team want you to be happy and producting using Python on the ArcGIS stack.
Please keep in mind that we can't include everything requested as there is a lot of work in testing and integration for each library ([Windows|Linux]x[32 bit|64 bit]x[Many other factors]). For example, I had to help with a workaround for a memory leak in matplotlib that was causing many spatial statistics tools to leak huge amounts of memory. And what would pywin32 look like on Linux? Adding a third-party module means adding an additional dependency in ArcGIS on that third-party which may or may not update regularly or anywhere in sync with our own timetables. Our release dates and the release dates of the third party can result in scares for us: numpy didn't have support for Python 2.7 until a week before 10.1 beta's cutoff date, so we almost had to stick with 2.6 for 10.1. I can only imagine how much closer (or over?) we would have run if we had a scipy dependency on top of that. And the opposite is true, too: we started with upgrading to 2.7 in our daily builds when it was first released, updated and tested 10.1 to Python 2.7.2 during the development cycle and then 2.7.3 came out right before 10.1's release date. I can see one or two libraries being frozen at a version you don't like (maybe they're crashy or have a bug that only existed for a few builds or have awkward APIs which are later fixed) on every install of ArcGIS, and fear that could cause more pain than the hassle of shipping your own with your tools. Not to mention the entirely unknown quantity of not just porting ourselves to Python 3, but waiting for all our third-party dependencies to port as well.
There's also reduplication of functionality in a lot of these libraries. I agree that we should get our GDAL bindings actually shipping and not just on the resource center. But on the other side, there's no realistic use case for Shapely considering ArcGIS already handles geometry in a very flexible, intelligent way. The only missing part is that it needs to be provided to you in Python. We exposed the relational operators in 10.0 on geometry objects, we added topological operators in 10.1, and 10.1 SP1 will ship with improved interoperability with WKT and Esri JSON. Another example is with time zones. I like pytz and I'm used to using it, but ArcGIS ships with its own time zone database and its own way of doing things with the time-aware stuff that came with 10.0, so instead of bundling pytz with its own parallel time zone database I went ahead and integrated the ArcGIS way of doing things as arcpy.time, which had the additional benefit of the smart time delta class that uses ArcGIS' time APIs. This then also negated any specific need for dateutil, which is another library I really like. But arcpy.time handles standard Python datetime and tzinfo objects so it all interoperates just fine with everything else, and the skills you learn either from arcpy or pytz/dateutil transfer without a hitch.
Again, I will check back here frequently. Let me know what you think should be considered absolutely essential to Python to include in the ArcGIS stack going forward.
