XHTML benefit is in the server production side. If you need to change a lot of pages you can use XSLT to change the pages or use XPath to look up entries. This is a neat technology, but people are still learning how to use it.

to my understanding XHTML was implemented to bridge the HTML & XML paradigms, and as such was not intended to be an evolving "language."

I still see no reason why companies should be rushing towards it. I understand when it would be useful, but I don't think there's a huge benefit for it, yet. What you're saying has been traditionally done with a backend language and has been faster and easier to implement. Trying to parse through fields using DOM/SAX could be time consuming. But then again the benefits of controlling the data in a structured way and presenting it (using CSS or XSL stylesheets) does seem very appealing.

Now don't get the impression that I'm against XML. This post is in regards to XHTML (referring to the presentation layer). I just think that there's no need to rush towards it yet, but I guess it wouldn't hurt.

Using XHTML can be tricky when implementing a CMS. Some CMSs (like Spectra) can have a free form container where the user can take clump of HTML and make an object out of it to put on a page. Now, one of the reasons CMSs exists is so users don't have to worry about technicalities, just about their content. So if they DO create an object where they just paste HTML, most likely (if they're not a techie) it will not be XHTML compatible.

There are a few converters out there (HTML-->XHTML) but none of them are 100% accurate. You know you always get the one exception where a user puts crazy HTML and then it breaks the parser (or get unwanted results). However, it can still be done.