Oh this brings me back. My first real coding job in 2003 was with a startup building dynamic user interfaces with XML, rendered with XSLT from the underlying data.
It wasn't perfect, but it did feel correct, in the sense that a UX should be ultimately a pure function of data. Which is an idea that has never gone away.
2005-2007 I worked on a webapp where the app layer rendered to XML, and then optionally server-side applied an XSLT transform to generate either HTML, RSS, or Atom, but you could also request the raw XML (and browsers could apply the XSLT client side, but for debugging/testing it was great to be able to then also see the underlying XML.
It had some benefits in terms of enforcing strict separation as well, but it was also painful to deal with the many deficiencies of XSLT (e.g. try reformatting dates...) that meant the XML ended up having annoying redundant values where it was easier to provide multiple versions of the same value than doing the conversions in XSLT.
These days I'm doing something similar by having apps return JSON and having the I built dynamically from the JSON with javascript, and I like that better than the XML => XSLT as much as "in principle" I agree with you that the pure approach of XSLT feels "correct". It's just too painful to apply as-is.
It wasn't perfect, but it did feel correct, in the sense that a UX should be ultimately a pure function of data. Which is an idea that has never gone away.