I can’t speak to SOAP specifically, but I did build a plugin (private) for a client once that had to communicate with a proprietary third-party web service. In this case, it was a non-RESTful interface which used a mix of querystrings and XML POST requests for submitting queries (depending on the complexity of the type of query), and returned result data in XML.
I built PHP classes to help abstract out their service into an API I could deal with more easily, and to smooth out the inconsistencies in their interface and the different types of XML documents they accepted and returned. Also, by creating my own abstraction, I hoped to safeguard my code against future changes on their end. If they kept the same basic structure for organizing data, but switched to a JSON encoding, for example, most of my business logic would remain intact, and I would only need to rewrite my request and response pieces for encoding/decoding the data.
While not specific to your question, my past experiences with SOAP have been mostly negative. There has been a long-standing battle over whether SOAP is an RPC service, or a document transport. Couple that with complications arising from slightly non-standard implementations (search for articles about using perl’s SOAP::Lite module with a Microsoft SOAP server, for example), using XML namespaces, and other factors, and you will get frustrated pretty quickly.
I wonder, though, if your question is more specifically along the lines of someone building both the client and server-side SOAP pieces? If I was building a web service (and associated WordPress plugin to access it), SOAP would definitely not be my first choice for the API RPC or data transport.