Looks like you've understood it perfectly. :)

Assumptions not necessary - my app loads the config file for them. As
for "weirdly formatted", well, let's take an example:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
   <userSettings>
       <MyCo.MyApp.Properties.Settings>
           <setting name="update_frequency" serializeAs="String">
               <value>100</value>
           </setting>
       </MyCo.MyApp.Properties.Settings>
   </userSettings>
   </system.net>
</configuration>

Is it easier to say to a user "if you want to change the update
frequency from 100 to 200, change the value of 100 to 200 in this file
and save it. Or, is it easier to create a new form, test the new form,
document the new form, and put the form through change control every
time a new value is needed? For simple applications, I think (and
indeed know from experience) that the TCO for the former is less in
the long run. Bear in mind that MS have assisted this approach by
ensuring that if they mess up the file, it'll just revert to default
values anyway - so it's not like I'm asking them to edit the registry
or anything. It was this layer of protection provided by the Settings
class that made me think that MS had done things the way they had (and
the fact that users get their own individual config files) to make it
easier from a programmer's perspective to allow users to edit their
own config files.

However, if I understand you correctly, you think that users should
never be let near an XML formatted file? (Interestingly, the app I am
thinking of, which is used by about 400 people, has about 10 settings.
The level of user capability varies from people that can barely switch
on the computer to those with MCSEs. Now, the former category don't go
near the config file because it's scary! The latter do because they
know what they're doing. Either way, I don't recall a single support
issue from a badly edited config file.)