I think he is referring to sending it to the browser as MIME type application/html+xml, which causes the browser to throw up an ugly error page on any markup error. This idea was quickly abandoned since a tiny mistake could cause your entire site to be broken.
Or possibly he is referring to actually validating XHTML, since errors often reported by the validator do not matter as far as rendering goes. If this is the case, I personally disagree: validate your damn HTML.
That's, probably, because most (IMHO) sites are hacked "live", by modifying code right on the production server. And there're no automated testing involved, at all.
With proper development process (with development->staging->production cycle), and fair tests coverage, there shouldn't be any problems with strict XHTML validation. Except for human laziness (I'm guilty too, of course) and lack of easy-to-use "here, install this toy, fill in this five-line config and deploy with just one command" tools.
Yes, with the exception of sites that allow user-generated HTML, you could be fine. My take is that having strict validation on the users' side does not add any value to my projects. text/html works just fine.
Or possibly he is referring to actually validating XHTML, since errors often reported by the validator do not matter as far as rendering goes. If this is the case, I personally disagree: validate your damn HTML.