Even xpath 1 let's you filter elements based on arbitrary sub-paths, so e.g. you can do stuff like //div[@data-marker]/span[i] - and match spans containing an i that are themselves the direct descendants of a div with a marker attribute. In css matching on content is in general impossible, with a few small exceptions like :empty, which is of course much less powerful. XPath will also let you select based on text-content, and select non-elements like text-nodes too. Also, it's likely much easier to make slow xpath selectors than css; oh well (but although I wrote quite a few XPath selectors back in the day, this was never a practical issue for me, which is perhaps also because unlike css - which is often used in huge quantities to match entire documents - XPath is more typically used to find just a few critical elements. I've never worked much with XPath 2, but it's even further in the direction of a kind of SQL for tree structures. By no means was XPath without weird limitations, make no mistake; but it's definitely more practical than css for finding specific elements in a messy tree especially when you don't control that 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.