Yes unfortunately XHTML is gone.
Adding 1 more reason to MainMa's great answer:
When XHTML was created, it was meant to be used by WebApps to serve structured content that would be understood by non-browser softwares, that would not have tag-soup HTML parsers. For ScreenReaders XHTML is still great, but for any other kind of software, WebServices fit that need, and they mostly use XML or JSON. SOAP itself has its own XML Schema, simpler than XHTML and operation-oriented.
As long as I know, there's not even 1 WebApp in the world that serves the same HTTP message to both browsers and other clients. Even REST architecture, which was meant to serve the same representation of a content in multiple content types based on client's preference, isn't used to serve XHTML/feed browsers.
In Java EE for exemple, using Eclipse we can deploy a unique war file holding Servlets+JSPs to serve HTML, together with Axis2 to serve a WebService. It's simply easier to develop separated softwares aimed for browsers and WebService than have a unique, complex software that serves them all.
The major reason for REST being rejected is exactally the complexity (and it was meant to be simple!) of developing a server that serves the same content for any type of client without knowing anything about it. And it's also hard to handle Web's need of fast evolving, together with keeping a stable definition that would not force non-browser clients to be updated everytime a XHTML changes, say it to keep the XHTML valid when it's built by many different modules.
In the same way, it's very harder to develop a non-browser client that parses a XHTML document, even it being valid, because of all those XML elements that are meant to structure the browser-rendered layout, and not meant to hold content.
If REST adopters already complain about SOAP's XML complexity, which is WAY simpler than a XHTML meant for a browser, imagine how hard it is to handle XHTML for multiple client types, server and client-side.
In practice: use HTML, XML-like if you want, to build WebSites for browsers, and any kind of WebService solution for non-browser clients.
BUT, I also think that XHTML5 must be created. XHTML 1.1 (ok, 1.0, 1.1 is unusable) will become outdated with HTML5, and we still need a validator that accepts HTML5's elements and validates XML wellformedness.