Are you meaning in my comment, or in the GitHub repo the article references?
Asking because AFAIK the theory of having (accurate) vendor provided WSDL/XSD files is that you can generate a bunch of code (ie parsers, strong validation) that works with it, generate tests. There are additionally well developed SOAP specific GUIs (ie www.soapui.org) which will directly load the WSDL/XSD files and let you immediately make test network calls to validate things.
Though sure, you can do the above manually without WSDL/XSD files, but if you have accurate ones provided to you by vendors then it makes things a lot easier.
Which is also my experience too.
Or have you not dealt with decade+ long services with severe inertia/lockin? Because that is what lets them get away with this.
Correct, yes I haven't.
Other members of staff where I'm working are from Java backgrounds, and have described (in detail) WSDL/XSD (when things are accurate) in positive terms as I put above.
And yeah, I'm presently dealing with vendor specs/docs that don't match what's actually sent over the wire, and it's a huge pain in the arse. And the vendor doesn't give a shit, as like you allude to they're in the telco business so the lock in aspect you mention is correct to. :(
Most places in my experience just write their own wrappers/frameworks to generate what they know works, and go to town. I’ve done it too.