Here are some considerations not mentioned so far, that may or may not be relevant, depending on the application you would want to use this for.
Integrity check of the configuration
With a single config file, take a cryptographic hash. Done. If it differs next time you read the file, then you know it was manually modified or got corrupted.
With a filesystem based config, you need to traverse the whole tree, reading items in a specified order before feeding them one by one to the hash. Not only the file content, but also the directory and file names. Quite some things to do.
Related to this,
Even if you have integrity checks, then there is so much more that could go wrong within a file system. Just think about a user looking through the files, moving some files/directories to other locations, with his uncareful mouse movements and a nervous finger.
How would you handle a link to a parent directory that throws you into an infinite loop when you traverse it unchecked. With the right corruption that is not checked by your application, it may as well be rendered completely broken, requiring an uninstall, manual cleanup and a reinstall.
A backup of a corrupted config file is so much easier to restore.
Talking about backups,
Power users and administrators
What may they want to do?
- Modify it in ways that are useful, but not possible with your builtin configuration dialogs.
- Backup and restore of the config.
- Export/import of the config.
- Transfer the config to a friend or to their second machine.
- Rollout a mandatory config to a large number of machines and users.
With a single, text based config file, everything you need is already built into the OS: Copy, move and rename of files, a text editor, copy and paste. The transfer is as easy as attaching a file to a mail.
With the filesystem, everything that is not provided by your application is hard to do. Manually modifying a text option? Better take care not to add an additional End Of Line. Modifying a binary option? Hmm, hex editor?
Transfer the config by mail? You need additional tools: Build a zip file and attach it. Then hope that the binary options inside won't trigger the mail virus scanner and that it gets through.
For all practical purposes, a filesystem based config is as good as a black box for a non-programmer.
EDIT: Cluster size
A separate file for each option may use quite a lot of hard disk space. When each 5 byte option eats a full 64KB cluster, and you have a lot of them... Do the math.