He thing about soap was that it was not simple. You had a full object model which was separate from your language and used different semantics. Operating it require a library which wasn’t often nice to work with. It’s the same argument against ORMs. If the library is bad, the ORM becomes a worst common demonominator interface.
What I said: it looks at the whole story, rather than piecemeally stitching together a stack. The downside is that it's maybe overwhelming, especially with multiple competing protocol specs and stacks doing the same thing.
As to XML: IMHO actually XML isn't a good fit for most API payloads. XML comes from markup languages/SGML which model semistructured data as regular content models, rather than co-inductive data structures of programming languages. The thing is, though, that the alternative, JSON, is really too basic (doesn't have schema-based validation, doesn't have date datatypes or enumerations, hell doesn't even have decimal numbers, etc.) Part of the story why JSON is so popular is that it's untyped and you don't have to agree on schemas, typed payloads, etc. upfront, and can just begin coding - but that also means you don't have typing, service contracts, etc. as your apps mature.
The format of the api (and its' payloads) also depends on the purpose of the api.
If the api is meant to be tightly coupled to an app, and is designed for that specific purpose, there's no reason to use anything like xml (or even, json) - it should be compact binary and minimal footprint.
If the api is meant to be general and apply across a range of client environments (e.g., you're selling this service api, and you dont know how or what your customer might use it for), it makes sense to make an api that's using an open format (like json, or xml) and have easily able clients in multitude of languages.
JSON Schema and Swagger/OpenAPI provide some of the missing functionality described above (type definitions, enumeration, validation). It's not quite the same and in particular I'm not sure I've seen a reference to the schema passed with the json itself (although that could easily be ignorance on my part).
WSDLs will tell your tools how to build the SOAP XML for you. It will even give you things like required fields and field lengths. When you need to update something just update the WSDL and regenerate your messages.
I love REST and JSON. The WSDL is one of the only things I like about SOAP. I’ve had issues where people didn’t give me the correct JSON or they update their scheme without notifying everyone and it breaks. You still need to notify people about WSDL changes.
I have brought this up a few times in various organizations and most of the reaction has been along the lines of "ugh, XML bad!" but a few have pointed out that there are several things in the JSON ecosystem which have evolved to basically fill the same niche. Swagger or whatever they call it now is usually the first thing that comes up. I haven't really had the experience of having an API to work with that just handed over a swagger file in the same way so many did with .wsdls back in the day, though.
The best thing that REST still doesn't do well is that you can point your tools at the SOAP discovery address and they will generate all the stubs for you, CORBA style.
Except that, it is mostly like REST. With a very convoluted specification that you can't hope to match on your own code (so, use tools), and tools disagree on the details (so, be careful to avoid the details).