Our configuration system started with just a single file, and evolved in what we have today.
Not only is there the .CFG file in play, but also the .EXT (Extended configuration), and finally the .LYT (UI Layout) files.
The LYT files are managed by the UI library that we are using, we do not manage them other than specifying which folder to store them in.
The extended options file is supposed to contain settings that are more related to the user: MRUs, Grid columns visibility and width, etc.
The issue with the main cfg file, is that the goal is for it to contain all settings that can be deployed by our custom installer (Custom Installer Service). That is fine for most, but the issue is that not everyone agrees on what should be imposed by the sysadmin, and what should be customizable by the user. We'll never get conscensus on what should be in it therefore we must make the best decision we can with the information we have.
Also, I must admit that some settings from the cfg file could/should be moved to the EXT file, but thats not something that is being brought up by our community. The requests we've had were to block out end users, so thats why we've added Administrative Templates (GPO). (How-To > How to apply policies). If we had to redo that configuration layer, it would mose likely be a multi-layered engine with overrides instead of each setting being defined in one place only, but thats a major undertaking.
As for you strategy, its what I would have recommended. Paired with using our administrative templates, you could disable File- Options, maybe File-Data Sources, and many more.
Apart from opening both cfg and ext files and having a browse, you could ask how a specific option is managed and we'll be able to tell you where it is managed from.