There are places that will save all the default values into the config when (if) the user first saves the page. I think this is true for a lot of "Advanced settings" pages.
e.g. For Unbound Advanced Settings, if Save has never been pressed on that page (which often happens - the user has no reason to mess with anything there) then those settings are not in the config at all. The back-end code has hard-coded defaults that it uses if the setting(s) is not specified in the config.
After the user presses Save on Advanced Settings then all the settings are written into the config, even if the user changed only 1 (or none) from the default values.
In the new GUI it should be easy enough to have a flow like:
a) For fields that have no value currently set, display the default value in grey in the field, waiting for potential user input. For drop-down lists, what to do? Select the default value, but remember that it is just the default and not actually selected by the user?
b) When saving, just save to the config any fields for which the user has actually entered a value. For drop-down lists, I guess only save the value if it is different to the default.
One the benefits I see of not storing the default value in the config is that it becomes easy to decide if the user has specified a particular value or not. If there are upgrades where we want to change the default, then it becomes easy and there is nothing to upgrade in the config. The back-end code will simply use the new default value because no value is specified in the config.
At the moment, with Unbound Advanced settings, it is not possible to know if the user has specially chosen the value of each setting (and for many of them has specially chosen what happens to also be the default) or if they only wanted 1 special value and "got the lot" because they were on the same page. That makes it harder when doing future upgrades that change a default.
All the default values for these sort of settings can easily be stored in some "inc" file(s) where the code that needs them can get them efficiently. That is another thing that could be done to consolidate some places where the literal default value is in back-end code, GUI default setting and written in some help text. All those should get the default from the same place, to avoid the problem of things getting out-of-whack.