And REST is easier to debug.
This make a huge difference when you have a big and complex system.
If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of headache going forward.
For example, I work on an application that has reasonably tight integration between pagination on the front end and parameters / headers on the back end. Works quite well, particularly since we can control both ends. It's not completely ad-hoc - we chose one specific idiom for pagination that had reasonable support, but not necessarily the most widespread - and then extended it slightly when we needed a few operations that had no direct support (e.g. multi-delete, multi-update).
But if you're integrating from everywhere, there's no upside on a unifying standard because any unifying standard will either have so many wrinkles, complexities and caveats to cover every special use case that nobody will implement it correctly or understand it correctly; or it will be ill-suited to many domains, forcing a poor mental model, increasing the probability of bugs and reducing extensibility.
Once people start exhibiting excruciating pedantry in designing their APIs, I'll switch off somewhat.
Many languages support auto generation of consumer and producer code based off of WSDLs.
And AFAIK, most languages that don't have the auto gen tools do have XPATH libraries for easily manipulating templated SOAP requests.
It takes just a few clicks to generate complete set of requests from WSDL (set, as in "one request per each operation"). I think it's much better user experience than hand-crafting json to use with curl.
SOAP's big problem, IMO, was the crazy insistence on URI formatted namespaces, which took a simple XML message and turned it into something bloated and confusing.