There are quite a few alternatives available to Web Services these days:
REST / HTTP Invocations.
You can argue that WebServices is SOAP/HTTP(similar), but implementing WebServices is far more complex than other integration mechanisms. Even the original idea of discovering WebServices (via UDDI etc) seem to have been lost now.
What do you think: is the complexity involved in WebServices justify their usefulness?
Google Docs - provides REST-Style/HTTP calls for invoking its services. It does not provide WebServices interrface. This is true of many such integrations as well.
You seem to be equating "web services" with "SOAP-based services". But the technologies you mention are not alternatives to "web services", they are alternatives to "SOAP-based web services". So the question you seem to be asking is really "What's the benefit, if any, of SOAP over REST (and/or other HTTP/XML service approaches)?" One of the benefits are the capabilities that come with the full SOAP stack as implemented by the various WS-* standards, like WS-Security and BPEL. If a particular service implementation doesn't need those, then, indeed, the overhead of SOAP may not be justifiable.
True, UDDI has failed to take off (although, interestingly, a new version of the standard is forthcoming), since web service registries in general have not established themselves. But that's not a failure of SOAP, that just means that the market has developed in a different direction than originally anticipated. So it can just be ignored, and doesn't add any complexity to SOAP itself.