> ISO/IEC 5218
Look… How often are you referred to ISO/IEC 5218 standard, honestly? Me — it very well might be that you're my first. But it's nice it's there. If it wasn't, I wouldn't be very sad, because M/F/None was probably enough for me so far (and is actually way more permissive than most of actual protocols where I had to specify human sex, which usually allow just M/F).
ISO 8601 on the other hand… First off, datetimes are everywhere, and are used constantly. Second, datetimes are far less trivial, and it actually requires some good amount of thinking to come up with a good representation. It is even more complicated to communicate that specification in all of the details. So, forget about whether ISO 8601 exists or not — the fact is, that I need a datetime standard. I need it every day, many times a day. Everyone needs it. Everyone comes up with his own shitty standard at least a couple of times during his life. Nobody can really communicate his own shitty standard unambiguously, covering even most popular corner cases, because only very rare people actually thought about the problem half as much, as it has to be thinked about to come up with something remotely good. And since pretty much everyone even acquainted with a notion of "standard" regards ISO as the "standards organization" we end up referring each other to ISO 8601 often enough that I know what one is talking about without actually googling the code. Technical people almost consider it a virtue of not coming up with their own standard, if there already is a usable one (and for a good reason). Long way short: ISO 8601 is important. Way more important than ISO/IEC 5218 or some meme tea-making manual. And it doesn't live up to what is (and, my point — should be) expected of it.
The range of what HTML allows is far more used in practice, in my experience. Which is kinda sad, because "HTML date format" isn't really format I should be referring to, ever, it's ambiguous, it's not commonly recognized, and it doesn't even account for a number of very important use cases ISO 8601 accounts for (date ranges, for one).
Now, I'm not sure which part of your post would I quote, but basically you are missing my point in the whole second half of your post. You are spending a lot of time talking about "T vs space" (which, unfortunately, might require that much time talking about and more), while this is really the trivial thing, everyone would get on the go, since it's so commonly used. So, because it's so intuitive, it's the part of the problem that begs about being standardized the least. What really begs for a standard are all these less obvious situations: 2-digit years, years before 1582, years BC, years after 9999 — which, unfortunately, are really not that uncommon. Honestly, they are common, even.
And while — as I said from the very beginning — ISO 8601 does make some half-assed attempts to address all these issues, in practice it doesn't communicate any of possible scopes of values clearly enough. In effect, there are lots of applications, that pretend that they "parse ISO 8601 datetimes", yet you'll find out that, say, Python standard library just doesn't handle negative dates at all. Which is ok (I mean, bad, but understandable), but the problem is that you really have to think about it yourself to even find it out. And the big value proposition of having a standard is exactly that you don't have to think about all the details, you just rely on the fact that Wikipedia (a big, reputable project) claims that it uses standard X for the datetimes, and Python (a big, reputable project) claims that it's standard library function can parse standard X datetimes, and you just assume that someone did all the thinking for you already and they are compatible. And ideally there should be standard Y such that it makes it trivial to refer to X = Y-1 and X = Y-2 and see that they are, in fact, incompatible.
So in practice ISO 8601 just doesn't do what it should.