The pragmatic problem with strict XHTML validation
There is a pragmatic problem with strict XHTML validation (well, several, but I'm only going to pick on one right now). It goes like this:
Strict XHTML validation in the browser clearly punishes users. If there is more than a trace amount of actual XHTML problems, this means that not doing strict validation is significantly more user friendly and thus a significant advantage for any browser that is not XHTML strict.
Given that you are punishing people by failing strictly, you are effectively engaged in a giant game of chicken with all of the other browser vendors. A policy of passing up the user friendliness advantage of non-strict XHTML validation is sustainable only as long everyone passes it up; the first significant browser vendor to break ranks will necessarily cause a massive stampede for the 'graceful failure' exit. And sooner or later someone is going to break ranks.
(This game of chicken is made more unsustainable by the fact that Microsoft IE is not even playing yet.)
I don't think that hoping for only a trace amount of XHTML validation failures is realistic. Even with the most optimistic view of content generation (where all XHTML content is automatically generated or checked) here are bugs and oversights in automatic page generators, and for that matter bugs and oversights in validating parsers. My pessimism says that someone is going to get something wrong sooner or later, even in widely used software.
(In fact my personal view is that strict XHTML validation has survived until now only because almost no content actually is XHTML. In the real world of the web the only commonly used 'XML' formats are syndication feeds, which are often invalid and are never parsed with strict XML error handling by any feed reader author who wants actual users.)