The reason for that is that you still want to be able have an XSD to validate.

In the context of SAML, these values are completely arbitrary metadata without fixed meaning in the protocol itslef.

You could even use attribute names that aren't valid for XML tag names.

It's the same reason why -- for example -- AWS APIs return tags as a similar entity list. You don't see

    <Name>Example</Name>
    <BillingGroup>prod</BillingGroup>

but rather

    <tagSet>
      <item>
        <key>Name</key>
        <value>Example</value>
      </item>
      <item>
        <key>BillingGroup</key>
        <value>prod</value>
      </item>
    </tagSet>

---

Database EAV would likewise be 100% appropriate if users could use the database to store arbitrary attributes. (Think JIRA custom fields.)

But if users are limited to certain attributes, then encode that in the schema.