I interned at a company with an XML+XSLT based MVC framework once. I actually thought it worked really well and generally agree with the article. A lot of more "modern" template and transform solutions are aiming for the same goals: sandboxed, side-effect free, limited logic, and so on.
I especially like the power of combining XSLT with Batik and FOP. You can take backend data and present it as an interactive table, a visualization, or a PDF report really easily.
I will say that the syntax is awfully obtuse, though. I find that support for various powerful-but-obtuse 1990s/2000s solution stacks splits along an IDE-user line: those who use IDEs are generally comfortable working with XML and XSLT in Java while text-editor devotees tend to hate that class of solution.
It's not so much obtuse as verbose. It's proof that hell is paved with good intentions: for simple transformations, it feels pretty natural. Unfortunately, once you need something a little more complex, it flies straight into a wall with "XML is not a programming language" written on it. "Function" calls with horribly verbose syntax, etc. Some solutions let you use a real programming language and have the XSL processor trigger your callbacks, but I've never experimented with it.
Alternatively, something Perl's Twig let you manipulate the DOM without too much of a headache, and is preferable to XSLT in many cases.
I got tired of updating my resume in Word then Manually generating PDF and massaging a plain text export into something decent. Now I write one document in ReST that is converted to Docbook (with XSLT) then run the Docbook through XSLT to get the meat of a DocX, XSLT to get an XSL-FO derived PDF, and XSLT to get an HTML derived plain text. Obtuse but powerful.
ReST syntax is more sophisticated than even the Pandoc flavor of MD. The ReST parser in Pandoc is very limited and its Docbook output is very restricted as well. It's a nice tool but not there yet for complex documents.
I especially like the power of combining XSLT with Batik and FOP. You can take backend data and present it as an interactive table, a visualization, or a PDF report really easily.
I will say that the syntax is awfully obtuse, though. I find that support for various powerful-but-obtuse 1990s/2000s solution stacks splits along an IDE-user line: those who use IDEs are generally comfortable working with XML and XSLT in Java while text-editor devotees tend to hate that class of solution.