XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages.
Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.
XSL is a functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function.
Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad.
The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements.
XSL's "escape hatch" is to allow arbitrary Turing-complete transformations. This was always intended to exist, to make easy transformations easy and hard transformations possible.
You basically never need to write Turing-complete code in a type system, but in any meaningful XSL project you will absolutely need to write Turing-complete XSL.
XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled.
Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.