It's not without its wobbly bits, but show me a language that isn't.
1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project
2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations).
XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.
I don't think I agree about responsive css, but that's another discussion.
It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general.
If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant.
And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example.
[0]: https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/
Product Manager - Figures out what new features or changes the product needs to better fit or find a new audience. Usually responsible for doing market research and analysis.
Business Product Owner - Similar to product manager, they own all changes associated with a company product. Position should only exist if product is so large, multiple product managers are needed for it. The product managers would then need to report to or clear their work past this individual.
Program Manager - Everyone above reports to this person. They own all of the products. And possibly oversee development as well.
XSLT is a programming language. It's not the usual kind of programming language where you tell the computer what to do. Instead it's a bit like a pattern matcher. If you have X kind of pattern, then do Y action. It's difficult to do procedural kinds of things with it, but it is awesome for transforming one kind of data to another kind of data. It reads XML files natively and you can output any kind of data you want (although usually you output XML).
We had a strange team which was heavy in "idea people". These people had the title "program manager" (or something similar). The idea was that they would have ideas and tell the programmers what to build. In practice, they had pretty crappy ideas and then we had to find a way to make them not crappy.
None of the program managers understood technology very well, but they latched on to ideas with a certain tenacity. One of these people found out that XSLT could transform XML. He also heard that SVG was written in XML. Finally, he also knew that there were many databases (at the time) that stored the data in XML. So he thought that it would be easy (in fact, automatic) to use XSLT to transform the data in an XML database to SVG.
The idea was to draw a picture using Corel Draw and save it as SVG. Then you would alter the picture using the data in the database using the magic of XSLT. Unfortunately he did not understand that XSLT was a programming language, and no amount of explanation would illuminate the situation. He was absolutely sure that if we added XSLT to our software then it would automatically alter SVG images in an intelligent way.
We had to take that idea and make a viable product. What we did was to make an IDE that allowed you to connect portions of an SVG diagram to data in a database. You used snippets of XSLT to transform the data in the database to transformations in the SVG diagram. On top of that, we built a GUI API that would give you a full interactive experiences using SVG rather than HTML (so you could build entire apps in SVG and hook it up to live data in a database). It was actually pretty awesome (and I take no credit for that -- we had awesome people on the team).
Unfortunately the "magic pixie dust" of XSLT was do heady a draw for the program managers and they got it into their head that you could automatically route circuit board diagrams if you had an XML database of electronic parts. This was a terminal mistake (and we warned them many, many, many times that it was impossible).
At the time of the takeover (Corel was bought by a venture capital company called Vector), we were treading water and trying not to drown. They mercifully terminated us, but unfortunately buried a pretty wonderful suite of software.
Hope that was more understandable/informative!
Of course the opposite is actually a brilliant idea (at least at a time when XML was still popular): Take an XML dataset and visualise it in SVG using XSLT transformations (well... yeah... doing it all in XSLT is still insane, but you get the idea).
Anyway, we built a very high performance SVG viewer (for the time, anyway) from scratch. We built an SVG/Javascript widget library. We built an incredibly impressive data manipulation library in XSLT (ok... yeah... insane).
Fun times. And all nearly 20 years ago. It really was ahead of its time. Of course the end finally had to come. The PGMs sold this thing to a certain aviation company with the promise that it would automatically build circuit diagrams from their XML chipset database (because.... XSLT!)
When Vector took over Corel, they very rightly dropped our division like a hot potato (we had something like 3 PGMs per developer). It was quite unfortunate because the developers and QA people I worked with there were some of the best I've every had the pleasure of working with. I've always waited for something to come of SVG and really wish we had been able to release something that wasn't crazy so that people could see what the potential was.
Edit: In my old age I'm losing track of time. It seems that Vector acquired Corel in 2003, so that's only 15 years ago :-)