I disagree.

There are plenty of legitimate reasons to want to have more complex data structures in a configuration than just a simple hash.

Also while there are plenty of configuration modules on CPAN, I haven't seen any that I like very much. Here are the main capabilities that I want out of a configuration solution:

1. Be able to have any kind of data structure into the configuration.
2. Be able to have a search path with selective overriding of configuration information. For instance the development and production configurations should be as similar as possible, with only a few key values being overridden.
3. Be able to selectively tie together the configurations of separate modules which should share some common information based on your environment.
4. Have checks so that if someone is trying to access a variable from the configuration that isn't there, you can catch it and fix.

On these criteria, most of the CPAN configuration modules score 0/4. Just using raw Perl as a configuration file scores 2/4. A simple bit of code that searches a configuration path and does every file it finds there with a specific name scores 3/4. And if you know what you are doing, it is possible to create a simple configuration module that adds the export checks.

Now those wants are not everyone's. Everyone wants to get different things from a configuration module (which is one reason why there are so many configuration modules out there). But I claim that my list is not an unreasonable set of wants for a Perl programmer to have, and if you have them then pure Perl is a perfectly reasonable kind of configuration file to use.