I largely agree with Raman's points. In particular, the problem of stuff building up in the custom file (or section). To make it worse, the format can be fragile, especially if you want to try and edit it to clean it up (not a big issue if your an experienced elisper, but if your not....). I have also experienced additional items being added to the custom section when I have used custom to set some values. At odd times I've seen values added which are not values I have customized.
It might also be worth having some sort of tool which could check custom definitions. I frequently see warnings about custom value mismatches. These are often caused when something is defined as a customizable value, but the code has changed and updating the custom definition has not been updated to match the code changes. Some sort of tool which check custom definitions for completeness and alerted developers to definition and initialisation mismatches might be useful.
Given the growth in custom usage, perhaps a better approach, rather than the 'custom section' or custom file would be to have custom write individual files into a ~/.emacs.d/custom directory? This could be based on the custom group or package name or perhaps add an additional field to the custom definition which specifies the name of the file to use. Emacs could then look in this directory at some pint in the startup process and consume the files in the custom directory or perhaps the require function could be modified so that libraries/modules look for a corresponding custom file when they are loaded? A big advantage of the individual files is that it is easy to remove a configuration and it wold likely be less fragile than the existing custom section. The drawback is that having lots of small custom files might adversely impact init time (unless you can do something like add it to require or load etc so that it is only read when the associated code is actually loaded).