In many applications (mostly enterprise), the extra overhead is well worth it because of the time it saves the developers. With .NET for example, you simply add the tag "[webmethod]" before the declaration of your method, and it becomes available over the Web. And if you're building the client, you simply point your tool to the URL of the service, and it immediately pulls the declaration of all methods along with their documentation if available, and also provides autocomplete and compile time validation on those remote methods. So, most developers don't even know about SOAP and never see a SOAP message. It's all done behind the scenes. If you're using a tool that doesn't have good support for it, though, then you're going to have a hard time with it.
wget http://weather.com/api?field=temperature&zip=02142
and get back a file consisting of "52" or something similarly simple.
Currently I have to get a 1k+ file and create a parser for it. I can't even find a really simple format that would allow me to use prebuilt XML parsers. If anyone knows of a dead simple API for temperature, precipitation, etc., I will upmod you at least once.
I don't think I've ever seen an instance of SOAP used appropriately, and I'm finding it hard to think of even a theoretical example where it would be a good idea. Maybe I'm not the target audience, but it seems to me the code, object size and data transmission overheads are almost never made up by any advantage SOAP offers. I think I'd consider ASN.1's XML encoding before I ever considered sending a SOAP message somewhere. At least then you could translate it to DER for efficiency.