I've encountered some uses of XPath to validate the semantics of XML data models (this kind of thing still has mindshare in some places - network devices for instance https://tools.ietf.org/html/rfc7950#section-7.21.5 ) and I've come to the conclusion that wanting XPath is usually a danger sign. It's helpful for manipulating content you can't control, but that leads to people designing interfaces and models that are too difficult to work with downstream. In document display settings that manifests as a content vs. presentation mentality where you have to write byzantine queries to wrestle data into reasonable output. In configuration use cases I've seen it lead to interfaces that claim way more general edit operations than the implementation can actually pull off, as people struggle to specify XPath-based constraints to make it tractable. It's much better if at all possible to have some kind of scripted layer to do transformations than to try to manipulate a general presentable-cum-semantic data tree.
On the XHTML vs HTML5 side, React at least does a good job warning you if you're trying to render something that violates DOM nesting (out of necessity as much as anything, since it will need to operate on the generated tree).
X-anything nowaways is pretty unfashionable, but in principle XPath would still be useful today; bit of a shame it's falling by the wayside without decent replacement. I actively try to avoid it nowadays even though I'm comfortable with it; usually the upsides XPath has aren't worth (to me) the lack of familiarity for other devs, and the potential lack of support in various platforms compared to css.
But on the sidetrack the parent comment mentions: In any case, I can unequivocally, whole-heartedly, so-verbosely-you-hopefully-understand-my-conviction on the matter support the notion that the html5 syntax was a disaster of the highest order. XHtml is a much, much better idea, and unfortunately it died. Anybody who's ever seriously tried to compose html safely and understands all the weird gotchas that can occur (oh that wrapper p tag got auto closed because the tooltip span contained an icon and those were implemented as divs? yay!), not to mention a syntax with so many exceptions essentially 0% of web devs actually know them all is just asking for XSS issues. You think your client-side SPA can do server-side prerendering reliable? Ah, but only if it sticks to valid html: including nesting rules, because although it will work without error clientside - the dom-tree is really just a tree without as many weird exceptions - lots of DOM trees simply have no html serialization. Doesn't exist.
To be perfectly clear: I don't think XHtml was particalarly brilliant; HTML5 is simply particularly atrocious.
If I could switch to a more comprehensible data-encoding format I would, in a hearbeat - especially since nobody writes raw html anyhow nowaways, it's all frameworks and libraries. And then you pray they correctly implement the html5 spec, because if they don't... it's not something you want to reimplement yourself.