The brainfuck is that it's purely declarative. It represents the transformation of one tree structure to another with no notion of sequential imperatives or as

The brainfuck is that it's purely declarative. It represents the transformation of one tree structure to another with no notion of sequential imperatives or associated concepts like variables and mutable state. This has some very distinct advantages: the execution can be very fast and parallelizable and predictable in space and time usage and secure in presenting nearly no attack surface for injections and overflows and such. This sounds great in theory. But the problem is real world business requirements don't work that way. Real specs are never a straightforward declarative transformation. They always include bells and whistles and rhinestones that don't fit into XSLT. Loop over this set and suppress records where this field matches the previous record (state!), or include pagination, or call somebody's web service in the middle of it to display today's stock price, or grab the user's preferences for colors and time zones. (All real examples from a job I had with XSLT once upon a time.) XSLT doesn't do any of that and isn't supposed to. So you add another layer of data munging in whatever produces the XML before the XSLT operates, or hack it in Javascript afterwards, and either way now you have two problems. Maybe XSLT skews high for income because it takes huge sums of money to get programmers to even touch the thing.