Configuration Files vs. Configuration Scripts
For people who like programmatic config files, one of the main benefits touted is the ability to use funcitons and variables. I want to set paths using expandpath or return URLs using cgi.servername or the like. I would argue that an XML config file has no place doing that because while those variables are required to make your application work, they are not static data but programmatic configs.
To me, the purpose of a static config file (e.g. an XML config) is to enter data which does not need to be set programmatically and which can not be set programmatically. It is to store pure data with a clean separation of concerns enforced by the fact that you can't use functions and the like within XML. Once you have read in that config data, you will probably still require a configuration script to configure all of the things that are dynamically set using code. In practice for smaller projects or projects where only one developer uses the code, it does no harm to throw all of this into a single cfm script and it keeps the app simple.
However, as soon as you have multiple developers working with the code, code you deliver to third party developers as a consultant or you are writing a framework that many people will use, the additional benefits of being able to check well formedness of the XML against a DTD and stopping people from writing scripts in the middle of the config data make XML a better approach for configuration files. You will still have a configuration script as well for the programmatic stuff - but you'll keep that well away from the people creating the config files, making it harder for them to get in trouble.
So, multiple developers, frameworks and code you're going to hand off that requires config data may well be worth using XML for that, but don't think this as replacing your config script. You'll still have a script that does all of your expand paths and cgi.servername stuff - it'll just be separate from the file the other programmers will use to provide data in.
