I think this is easier to show on an example.
Let's take this code, for example:

        <line>
            <str>{helmeticon} <var>helmetname</var>
            <op>
                <str>ge</str>
                <pct>
                    <var>helmetdamageleft</var>
                    <var>helmetmaxdamage</var>
                </pct>
                <num>50</num> <num>20</num> <num>10</num>
                <str>$e</str> <str>$6</str> <str>$c</str> <str>$4</str>
            </op>
            <max>
                <var>helmetdamageleft</var>
                <num>0.5</num>
                <str>{helmetdamageleft}$f / $e{helmetmaxdamage}</str>
                <str/>
            </max>
            </str>
        </line>

Expected result: [icon] Dark Helmet XX / YY or blank line.
Actual result?…

That's a lot of issues for such a simple construction.

1. Tags must be able to be freely nested within reason. I.e. no nesting <line> within <str>, but nesting strings must be possible.
2. The <var>tag</var> and {tag} must be equivalent. In fact, documentation explicitly says they are, but #1 prevents it.
3. All whitespaces within text blocks must be squashed before rendering. If one want to write multiple spaces, they can use <str> </str> to space away as many as they need. But I fail to see any reason to do so. If one want to align something, spaces are least useful.

That format makes no sense. Why would you want to nest anything inside a string? A string is a string, a simple data container that contains some text.

Your example, when properly formatted, makes no sense (not in the context of the mod and not in the context of pure XML):

<line>
    <str>{helmeticon}
        <var>helmetname</var>
        <op>
            <str>ge</str>
            <pct>
                <var>helmetdamageleft</var>
                <var>helmetmaxdamage</var>
            </pct>
            <num>50</num> <num>20</num> <num>10</num>
            <str>$e</str> <str>$6</str> <str>$c</str> <str>$4</str>
        </op>
        <max>
            <var>helmetdamageleft</var>
            <num>0.5</num>
            <str>{helmetdamageleft}$f / $e{helmetmaxdamage}</str>
            <str/>
        </max>
    </str>
</line>

Perhaps what you're really looking for is the concat function that joins together multiple strings/numbers/whatever?

<concat>
    <str>{helmeticon} </str>
    <var>helmetname</var>
    <!-- ... and so on ... -->
</concat>

"Pure XML" is largely a nonsense. XML just describes some basic structural rules, but it has no restriction on document's content.
And if you allow tag nesting, you will not need <concat> to begin with.

In the context of the mod, the structure is defined by the parent tag - the <line> tag. Everything within it is supposed to be a single line of text. How you construct it, is a different question.
If you take the approach of XHTML, where implicit text blocks are created on tag boundaries, you will not need any explicit glue to create logical blocks. They will be created naturally by the nesting tags.

All of the above is true for the XML format, but what about the alternatives, text and JSON? Having data in elements that aren't tree leaves makes it harder to process. IGI still have to evaluate every single leaf/node and having it all as a text node would only make it harder to process.

I have no idea, why you introduced these formats.
I can make text work rather trivial, but JSON? It's furthern from human-readability, than XML.

Originally there was only the text format available and XML/JSON were implemented at a later time.

Also, JSON is generally considered to be the easier of the two formats for non tech savvy people, assuming that the format/structure is the same.

I doubt that I'll be changing the way the XML format works, the current structure reflects the internal format of the data structure that is used after the config file is read. I do understand that an XHTML-like format would have some benefits, but that would mean that I'd have to ditch both other formats.

Got it. Thanks for explanation.