I've decided on a name for SOAP services that use XML strings for input and output rather than objects: Lye Services.
These services completely miss the point of the SOAP overhead, which is to hide the obnoxious XML string manipulation in the SOAP layer, to avoid the tedious and error-prone process of building XML strings manually via concatenation or templates. This means you get all of the drawbacks of SOAP (high network overhead, heavy library dependence, XML serialization load) without any of the benefit (a complete service description; straightforward updating; working with objects and not worrying about XML strings, serialization, de-serialization, and validation).
The result is a service definition that is not complete: the schema and documentation for the XML to input is elsewhere, usually out-of-band, that does not automatically update when the service is updated.
Worse still, these POX-y services often omit a schema for the input XML that could be used to generate or validate the XML before sending it to the service, making the process much more error-prone. Sometimes the service is so poorly specified or documented that the developer is forced into tedious trial and error to figure out the appropriate input.
Thus, "Lye", an archaic and harsh soap that homophonetically implies an untrue implementation.
When encountering a Lye Service, it's worth asking whether a more structured approach (objects, rather than XML strings) could be used. If not, REST may be a better fit than SOAP.