Yes, I'm working on FAA SWIM services now. The tech feels old school (UML, XSD...) but having documentation, class generation from XSD is very helpful.

These days new uses are mostly for public interfaces (business-to-business services like orders/invoices), services in regulated markets (energy, telco, medical) and eGovernment (tax statements and other financial reporting eg based on ISO 20022), as opposed to internal microservices. Other than that, it's kind of a "boomer" thing in the sense that it was the wire format to choose around 2000 when most businesses went online, and it just prevailed. Same thing with EDIFACT which was established earlier and still rules logistics.

The actual point of using a markup language for service payloads that aren't intended to be read by humans in the SOAP times was just that you can simply style it up (using CSS or XSLT back then) without having to go all the way to bring a full frontend toolkit/JavaScript into the stack along with insular know-how for merely viewing messages when your primary backend language was eg. Java.

No. Since browsers, the most frequent consumers of APIs, work directly with JSON, the API should return that. You can type (schema) JSON in TS and all LLMs are very good at reading, writing, and documenting it.