Oops, forgot to mention an obvious benefit for DU developers: eliminating a not insignificant quantity of code from DU.
What code would that be ? In the simplest case setup.py is quite trivial. It's only when things get more complex and require 'manual' fine-tuning that this script (or other user-specific modules it loads) becomes large. I honestly find this approach quite scalable.
In particular, all module metadata handling (parsing/generating/verifying) duties can be handled by a much more useful general-purpose modulemetadata module in the standard library, to which DU would become just another client.
what is the scope of such a 'module metadata' module ? And who would use it beside distutils ?
As I said earlier, I don't believe anything beside the already existing metadata (available through pythonic introspection) is needed or even useful for modules in general. What you seem to have in mind is important for *packages*, and that's exactly distutils' scope.
Whenever I hear 'general purpose' a little warning light flashes in my mind... :-)