On the other hand, it wouldn't take much doing at~all to modify something that outputs json into something that outputs xml.

yes. back in the day i would tend to wrap my database api in xml first in a standardised way and then i could just use xslt to return json or other formats from the api depending on the mime types requested by client. this fits in nicely with fielding's REST principles. all those technologies (HTTP/REST, XML, XPath, XML Schema, XSLT) actually work very nicely together and allow you to build nice systems that are very flexible, easy to integrate with and easy to change, even though they can be hard to make fast. maybe "move fast, break things" was a bad idea? =)

Why make your payloads bigger though?

yes, there's definitely a bandwidth overhead with xml compared to json. that was an important factor in the shift i suppose. but then we have things like graphql, which has pretty much erased all those gains. you can also do tricky things like using binary on the wire and transforming at the endpoints.

it would be nice to see if fundamental xml tech can be improved in a new hardware and software environment. afaik, there hasn't been much if any innovation in that space in recent times. would love to know if there has.

I feel like this is being rediscovered right now with htmx. Servers having their responses updated to give back html markup to include.

That functionality does in fact exist in the current versions of those programming languages, i.e. XSLT 3.0 and XPath version 3.1