When you have much more than one line of these "a=b", that sugar helps. XML has hierarchy, you can group related values into elements. XML has comments. XML can be typed, the standard even defines formats for numbers, date and time. There're good libraries to serialize/deserialize objects to XML, from pretty much all OO languages out there. I use them a lot, and I rarely expect users to edit XML, I give them GUI to change the settings they need, updating the config.
Well, the problem with INI files for configuration is that config files (legitimately!) need to be able to represent repetition, nesting, schemas and comments, which there was never any standardization for. While XML seems like overkill for something as mundane as a config file, the standard does at least cover all of the cases you need.
If your config is that complex, you might be better served by JSON - or the full JS or, say, Lua, for that matter. Because what you are talking about looks more like (interpreted) code than a config.
It's under- and mis-used, but XSD helps to validate config files and provide some guidance on the structure. I know JSON has a schema in draft, is it used much?
An example of XML config we used at my workplace was a processing pipeline with various modules and options/parameters encoded for each phase (some optional) of the pipeline. So in a sense it was configuration that resulted in executing code modules, not so much your standard options.
Why use XML when INI files are way easier to read, and especially edit if needs be?
Why add a ton of additional sugar on top of something as simple as "a=b" for config files?