The way we handle this in the shop I work for is to have a global, sitewide configuration that's split up into logical segments based upon what each part of the configuration is for.

When writing new stuff, we have a Config module set up that allows configuration segments to be loaded independently of one another, in the combinations that we usually use them in (for convenience) or all at once (for when you can't find the bit of the config database that you need *grin*).

By abstracting out the configuration layer, we ensured that the new code (and any old code) has no knowledge of what the data looks like on disk (it's actually XML at the minute): it simply gets served up a configuration hash from the config layer. If something about the file's structure needs to change, or even we move from a flat file to some other storage method, the change impacts only the config layer - no other code needs to be modified.

As far as "how much is too much" goes, I'm a big fan of reusable, configurable code, but not at the expense of readability and ease of maintenence. The time to stop adding configuration variables is when the code becomes less clear by using them, or becomes harder to maintain owing to the need to track down a load of configuration data, often split over a number of files, simply to see what a section of code's doing.