I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't.
I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.
I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances.
but that syntax... and of course a much inferior and more obscure language than scheme underneath dsssl.
I also have a simple playground for XSLT: https://xsltbin.ale.sh/
But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.
CSS and HTML have a dual relationship. You could certainly write CSS with an XML-like syntax but people would always get confused at whether they are looking at style or markup. Because HTML and CSS look completely different you never have that problem.
XSLT shares the same problem with the RDF specs coming out at the same time that it hid the production rules/logical nature of the system, had it looked more like
<someElement someAttributeattribute=$x/> -> <anotherElement>$x</anotherElement>
When I was looking for my own revolution in software engineering I saw one part of the low code/no code puzzle was that conventional tools force you to determine what order events happen which was something laymen shouldn't be bothered to do. Some counters are: spreadsheets (they figure out what order to calculate it), make (does a topological sort), dependency injection tools like Spring (writing a FactoryFactoryFactory isn't so bad, but maintaining it is a disaster when a "small" change means you have to reorder the order in which you construct everything)
There is a "freedom is slavery" problem here. People saw the semantic web as "you're going to exhaust yourself arguing with people about standards and ontologies before you even start coding" and not "if my data is properly namespace I can throw data from 10 different sources together into my RDF database and start writing queries".
XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.
It was actually great when you got it, but the learning curve was so steep many developers couldn't use it effectively to begin with. For complex pages only certain developers could make changes or fix the bugs. Precisely because it was functional and most developers at the time really only understood imperative.
In fact, I remember the DailyWTF had a WTF about using XSLT as client-side transforms a few years later:
https://thedailywtf.com/articles/Sketchy-Skecherscom
But doing something like that was in fact so much faster than doing it in js, and when you groked it (deliberate throwback), it was so much simpler. I actually wrote a pivot table control in XSLT which completely blew away the performance of the pre-v8 javascript one. Pre-V8 javascript was so slow most developers wouldn't believe you now. A 10,000 iteration loop of even basic operations was often enough to cause IE6 to show a pop-up saying the page wasn't responding.
The pivot table in javascript would crash with just a few hundred lines of data, in XSLT it was instant with even 10,000s.
A really interesting use of XSLT on the web at the time was the WoW character viewer. You could view (and share) your character on Blizzard's website, with all their gear, skills, etc. It was blazingly fast for the time and it was all written in XSLT.
The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on XML. This is convenient, because user interfaces are created manually. (I am not mentioning text markup, it is well known.)
Yet XML was often used as a notation for machine-to-machine exchange. For example, the ONIX book description standard. Here data are moved between two computers, yet for some reason they have to form grammatically correct phrases according to a set of grammar rules. Computers do not need grammar. They do just fine with non-grammatical data, like a set of tables. It is way simpler for them; parsing or generating grammar, even explicit, is pure overhead for data exchange and is only necessary when data enters or leaves the computed pipeline.
So, to your examples: configuration in XML is actually fine, but IPC is not. Configuration is written by hand, IPC happens between machines. IPC specification, on the other hand, is also a good fit for XML.
That said, XML and thus XSLT has another flaw: it is way too verbose and has no good way to format it. Conciseness was an explicit no-goal but now we can say it was a mistake.
Granted, it did seem that XML got more heavily abused than some other options for a while. I am curious if that is just a by product of when it was introduced. That or just the general proliferation of how many front end developers we have. (I hate that I am pushing that to almost be a complaint. I certainly don't mean it that way.)
XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures.
XSLT needs a Turtle-style syntax.
XML in general (the data structure, not the syntax) needs a Turtle-style syntax.
I choose to look at this a little differently.
An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon.
I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...