I have not used distutils very much, but maybe in some slightly unusual situations. I'll briefly summarize what I believe are the strong and the weak points.
- support for binary installers. (I was compelled to use distutils in the first place because it is so easy to create Windows installers - which is a massive pain otherwise)
- basic C extensions multi platform compilation support is quite good. Sometimes library names must be adjusted across Windows/Unix, but that is often enough and much less painful than writing multiple makefiles (GNU make and nmake at least, not to mention the inter-Unix differences)
- build processes with more stages than compile and link need to extend distutils. - insufficient SWIG support.
Both these weak points come from my experience with wrapping third party libraries into Python with SWIG. I typically generate the SWIG input files from the third-party headers and feed it into SWIG to get the C source, so I have preprocess, swig, compile and link as stages.
- I'd like the C extension build system to be more loosely coupled from distutils or opened up, if only by more documentation (I don't know SCons first hand)
- I'd like to continue to get information from distutils how Python was compiled, linked and installed.
Not all operating systems have a usable package management system (Win32, Mac OS X, probably others).
What's wrong with Installer.app and/or PackageMaker? On Windows, there is MSI (but I will admit I have given up in disgust trying to create even a trivial installer "manually" with Orca.exe).