> no apparent motivation behind this rule, except that of conforming TOML to JSON...TOML's reason remains somewhat mysterious.
No, it's not mysterious, you figured it out! TOML is designed in part to work fairly well with other common formats, like JSON.
> ...except that a value can also be a date. There is something intriguing in all this. Even forgetting that an application might not need dates at all, why constraining something so particular and that can be formatted in so many different ways into a rigid primitive?
Once again, you answered your own question. Dates can be formatted in many different ways, so TOML offers a standard date type. It's really helpful!
> And even if you do survive the process of writing a parser that is fully compliant with TOML (some people don't), you still have done only half of the job, that of writing a parser, without really thinking of any real case usage.
In my experience TOML parsers are more consistent than INI parsers in terms of behavior. They have been immediately helpful to me, as they support a configuration format I vastly prefer.
What a funny write-up. TOML isn't perfect, but I like it much more than INI.