You're ignoring the actual use case: people would view the XML with XSLT in browser and see a web page in a format that they could read and appreciate, and computers could read the XML ignoring the XSLT and get a dataset that they could manipulate for further purposes.

Consider an API that returns not JSON but XML: a human viewing that data in a web browser would see a web page depicting the data, while a script fetching that data would get the underlying data as an intelligible and manipulable structure for further operations. The example usually given was a CD tracklist: a human would get a readable list, while a script would get data about titles, artists, etc, and could file that in a music library or perform other operations on it. I worked with TEI: a human could read a book encoded as TEI and transformed by XSLT into a web page that reproduced the text of the book, but a CMS collecting texts into a corpus could pull bibliographic data from the XML and index the TEI file among others into a library. The main idea was that underlying data should be separated from its presentation, so that XML files would function as data models for different consumers, while XSLT transformed that data for human consumers, and automated consumers would operate on the underlying model. If you remember the late 90s and early 00s, separating data from presentation of data was a major goal, and XSLT did that.