The parts of XSLT that cause me problems are the functional programming parts; not every problem is well-suited to functional programming, especially when it comes to, as in that case, parsing complex interconnected documents to find information (ETA: Particularly when that information isn't guaranteed to be in any one particular place, and you have to conditionally check multiple locations, each of which itself may be referenced in one of multiple locations that have to be conditionally checked).

Functional programming takes a mathematical approach to problem-solving. There are some problems it is exceedingly elegant at solving. The issue is that it isn't any more elegant than a well-written alternative in another language, and it makes that elegance mandatory, which causes severe problems when you're dealing with an inelegant problem.

I'm not hired to solve elegant problems. I'm hired to solve the problems that companies have spent 20 million dollars to fail to solve.

That, to me, falls under "Trying to figure out ways around the constraints imposed by the language."

I suspect it would have made for even messier code, as well, provided it would have even worked for that particular problem. I was parsing a deliberately and ingeniously obfuscated document, and I was updating particular pieces of information based on information obtained in recursive references which, needless to say, were obfuscated, including false flag references which would get me incorrect information if followed; the falsity couldn't be determined locally, either, and required complex conditional comparisons to information contained in parent references. Some of the references were cyclical, to boot.