The original spec, "Anything that fits into a refrigerator," is a pretty darn good one. It conforms to Postel's law: "Be conservative in what you do, be liberal in what you accept from others".
We can develop a spec in a vacuum, but we can't be sure what users actually want from our refrigerator. Maybe a live penguin actually does belong in there, as in the famous children's novel.
HTML5 includes a well-defined algorithm for parsing such constructs, so with the HTML5 doctype that fragment is actually well-formed and normalized to the tree you'd expect.
That's right as far as I can tell. For another example of markup that's entirely valid in HTML5 but still considered icky by some people, the spec section on tag omission has an example of how to write tables more easily by skipping all the end tags.
Violations of the first part of the law are inevitable once the number of "implementors" of the standard is large, not least because that implies low average competence.
You can perhaps (but my confidence is low) avoid violating the first part of the law if you're a TCP stack implementor, say. There just aren't that many such implementations nowadays and they're generally done by people who know what they're doing. But applying Postel's law to something like programming language implementations, where the "implementors" who would need to obey the first part are all the people writing programs in the language, pretty much guarantees violations of that first part. For any given programming language anyone cares about in practice, the number of people who know the spec for it well enough to only write code that conforms to that spec, even on their first try, is _tiny_ compared to the number of people writing programs in the language.
At that point your only option is to accept that the first part is going to be violated, and badly. Only once you have internalized that understanding can you have a constructive conversation about whether you want to do the second part and to what extent. The answers here will vary, of course.
The alternative is even more against reality of what people do -- e.g. the classic proposal for a web browsers which would only accept very strict HTML (and this would supposedly make people fix their websites). In practice it would only have hindered the adoption of the web.
Yes! Things shouldn't prevent all the crazy that's out in the world... Users will try to find creative ways around requirements, being more graceful in handling the crazy is usually appreciated
On the other hand "Make doing the right things easy and the wrong things hard" are good design rules. Putting something alive into a refrigerator and leaving it there, will probably make it dead. It might be a serious mistake by the end user. The smart refrigerator of the future might want to double check; "Are you sure you want to put the milk in the crib and the baby in the refrigerator?"
We can develop a spec in a vacuum, but we can't be sure what users actually want from our refrigerator. Maybe a live penguin actually does belong in there, as in the famous children's novel.