I worked with XSLT a lot and I like it, but agree that a general-purpose programming language, preferably procedural, is more convenient and more powerful.

The reason XSLT is this way may be similar to why SQL is this way. SQL is declarative primarily because it isolates the user from concurrency. It would be much easier to write a procedure to fetch the data the way you want, but to write a concurrent procedure that does this safely and nicely among other such procedures would be much harder. XSLT was meant to be used with XML documents of unknown quality, so the logic of what is going on should be traceable. And XSLT did this rather well, given the constraints.

Upd: The constraints, as I see them, were that: the code will be written mostly by non-professionals (there were no professionals yet) so it should not be easy for them to get into an endless loop or otherwise shoot themselves in the foot. CSS faced similar constraints and was always rather awkward; nowadays it is also too complex and is only a formatting engine, not a transformation engine.

E.g. if XSLT was the main engine of the web CSS stylesheets would be unnecessary. The attributes could be placed on the elements themselves as this happens in XSL-FO. This would remove a major source of complexity; look at Tailwind, how popular it is, and why? Exactly because it removes an indirection step and instead of providing an external formatting rule merely formats an element directly.