XSLT is great, but its core problem is that the tooling is awful. And a lot of this has to do with the primary author of the XSLT specification, keeping a proprietary (and expensive) library as the main library that implements the ungodly terse spec. Simpler standards and open tooling won out, not just because it was simpler, but because there wasn't someone chiefly in charge of the spec essentially making the tooling an enterprise sales funnel. A shame.
Once upon a time HTML was a kind of XML, which is why the current version is very similar to XML and hence painful to write. This in turn is why we tend to use programmatic tools to handle the HTML, and you should if you work with XML too.
HTML5 is unlike XML in very important regards, which makes it actually quite difficult for tools to handle. But easier than XML. XHTML was quite annoying to write as far as I remember.
I doubt it was common. But, for example, there is such thing as Schematron: this is a special notation that checks that an XML document follows business rules and the final tool that it produces is a custom XSLT that transforms the document into the report.
(I'm also doing this currently; I need to prepare a sort of an annotated patch to an XML document, so I concocted a notation that describes edits and use it to generate both the documentation that highlights differences and also the patch itself; the patch comes out as XSLT.)
