Sim, infelizmente, o XHTML se foi.
Adicionando mais um motivo à grande resposta da MainMa:
Quando o XHTML foi criado, ele deveria ser usado pelo WebApps para fornecer conteúdo estruturado que seria entendido por softwares que não são de navegador, que não teriam analisadores HTML de sopa de tags. Para o ScreenReaders, o XHTML ainda é ótimo, mas para qualquer outro tipo de software, os WebServices atendem a essa necessidade e usam principalmente XML ou JSON. O próprio SOAP possui seu próprio esquema XML, mais simples que o XHTML e orientado à operação.
Desde que eu saiba, não há nem 1 WebApp no mundo que sirva a mesma mensagem HTTP para navegadores e outros clientes. Mesmo a arquitetura REST, que deveria servir a mesma representação de um conteúdo em vários tipos de conteúdo com base na preferência do cliente, não é usada para servir navegadores XHTML / feed.
No Java EE, por exemplo, usando o Eclipse, podemos implantar um arquivo de guerra exclusivo contendo Servlets + JSPs para servir HTML, junto com o Axis2 para servir um WebService. É simplesmente mais fácil desenvolver softwares separados voltados para navegadores e WebService do que um software complexo e exclusivo que atende a todos.
O principal motivo para o REST ser rejeitado é exatamente a complexidade (e era para ser simples!) De desenvolver um servidor que serve o mesmo conteúdo para qualquer tipo de cliente sem saber nada sobre ele. E também é difícil lidar com a necessidade de evolução rápida da Web, além de manter uma definição estável que não force os clientes que não são de navegador a serem atualizados toda vez que um XHTML for alterado, diga-o para manter o XHTML válido quando ele for criado por muitos módulos diferentes.
Da mesma forma, é muito difícil desenvolver um cliente que não seja do navegador que analise um documento XHTML, mesmo que seja válido, por causa de todos os elementos XML destinados a estruturar o layout renderizado pelo navegador e não a conter conteúdo.
Se os adotantes de REST já reclamarem da complexidade XML do SOAP, que é MUITO mais simples que um XHTML para um navegador, imagine como é difícil lidar com o XHTML para vários tipos de clientes, servidores e do lado do cliente.
Na prática: use HTML, como XML, se desejar, para criar WebSites para navegadores e qualquer tipo de solução WebService para clientes que não sejam navegadores.
MAS, também acho que o XHTML5 deve ser criado. O XHTML 1.1 (ok, 1.0, 1.1 é inutilizável) ficará desatualizado com o HTML5, e ainda precisamos de um validador que aceite os elementos do HTML5 e valide a conformidade do XML.