I think the point of HTML validation is that there was a time when there were many browsers that behaved incredibly differently with malformed HTML - the days when everyone was creating their own rendering engine and all of them were terrible; the days of HotJava and iCab. I'm assuming that the people back then assumed that we'd get more, not fewer, rendering engines to deal with and that if there were standard, valid ways of writing HTML, they could all conform to the standard and life would be good.
Little did they know that Microsoft would come along and tear down that world. Today, we've seen it bounce back a little, but really there are three rendering engines - Trident, Gecko, and WebKit. And, compared to what we had back in the Netscape days, they're all good engines. Sure, we might consider Trident crap by comparison to Gecko and WebKit today, but it's clearly a cut above what we were seeing in the Netscape days.
I think the reason that people today don't care about validation is that perfectly valid code can render differently in the three different rendering engines. If valid HTML doesn't give you the benefit of proper rendering, then what value does it give you? If a rendering engine is "wrong" in how it renders your page, you can bet that's your problem and not the rendering engine's problem - at least it will be according to your visitors. And three rendering engines aren't too hard to test - especially given the similarity in a lot of the rendering between WebKit and Gecko.
As for XHTML and HTML, Apple's "Surfin' Safari" blog has a great post on it: http://webkit.org/blog/68/understanding-html-xml-and-xhtml/. I guess XHTML never really fulfilled its purpose as having machine readable data in HTML - possibly eclipsed by things like RSS.
As others have pointed out, search engines also need to parse your pages to extract text and links. You can't really test if Google parses malformed HTML the way you think it ought, so I would say better safe (valid) than sorry.
I think the reason that people today don't care about validation is that perfectly valid code can render differently in the three different rendering engines.
This is exactly true and the reason is that web standards aren't real standards by the textbook definition of the word, mainly because they lack what's called a "reference implementation".
I forget where I read it first but the overall gist is that in other fields, say industrial design, a standard typically isn't ratified as finished until the governing body creates an example for everyone else to refer to, the reference implementation, rather than just relying on the written descriptions of how the thing should work. For example, Firewire has a reference implementation that's certified by the IEEE and that hardware makers would refer to when building out the first versions of it. You could grab the example version, plug it in the way it's supposed to, test out the data that's flowing through it, measure what speeds its capable of, etc.
Since web standards don't have that reference implementation by the W3C, browser makers are left to their own devices to parse the insanely complicated technical language on their own. And it's only getting worse - the html5 spec is something like 10x the amount of writing as the last version of html. This is one of the biggest reasons why rendering engines have effectively stagnated in the last few years - things are "good enough" that they can wait around until the spec makes sense and there's working examples in the real world, and/or they are spending a gazillion hours trying to figure out what the new specs actually mean.
This is the problem with functional specs that 37signals rails against when they say that "Functional specs only lead to an illusion of agreement":
This is a super sad state of affairs, and not just in the theoretical sense of how fast the pace of development could be for browser makers today if things were more streamlined, it's also a huge hindrance for developers in the trenches like me. I haven't thought about this for years but I used to relish reading the CSS spec and exploring new ways of pushing my work forward. Trying to read the W3C docs now is like speed reading pig latin - you know there's some cool stuff in there but it hurts your head just to even try hunting for it.
Little did they know that Microsoft would come along and tear down that world. Today, we've seen it bounce back a little, but really there are three rendering engines - Trident, Gecko, and WebKit. And, compared to what we had back in the Netscape days, they're all good engines. Sure, we might consider Trident crap by comparison to Gecko and WebKit today, but it's clearly a cut above what we were seeing in the Netscape days.
I think the reason that people today don't care about validation is that perfectly valid code can render differently in the three different rendering engines. If valid HTML doesn't give you the benefit of proper rendering, then what value does it give you? If a rendering engine is "wrong" in how it renders your page, you can bet that's your problem and not the rendering engine's problem - at least it will be according to your visitors. And three rendering engines aren't too hard to test - especially given the similarity in a lot of the rendering between WebKit and Gecko.
As for XHTML and HTML, Apple's "Surfin' Safari" blog has a great post on it: http://webkit.org/blog/68/understanding-html-xml-and-xhtml/. I guess XHTML never really fulfilled its purpose as having machine readable data in HTML - possibly eclipsed by things like RSS.