Nick Gall has a blog post entitled What were we thinking? where he writes

It just struck me, after 5+ years of analyzing the ins and outs of SOAP, how little need there has turned out to be for the SOAP binding model (i.e., binding SOAP onto various "transport" protocols). If some endpoint is going to go to all the trouble of enabling processing of URIs and XML (a prerequisite for processing the SOAP envelope), what are the chances that said endpoint would not go ahead and enable HTTP processing? The scenario of a mainframe endpoint that is able to process a SOAP envelope, but is unable to process HTTP to receive the envelope strikes me as ludicrous.
...
So who really cares that SOAP is able to be bound to MQ or IIOP or SMTP, today? Apparently, very few--since there has been virtually no progress towards standardizing any SOAP binding other than to HTTP for years.
...
Accordingly, it seems to me that the WS-* stack could be made a lot less complex for the average developer if the SOAP and WSDL binding models were simply deprecated and replaced with simpler "native HTTP" binding

This is one of those blog posts where I simultaneously agree and disagree with the author. I agree that a lot of the complexity in WS-*/SOAP/WSDL/etc has to do with the notion of "protocol independence". As I mentioned in a previous post entitled Protocol Independence is a Leaky Abstraction, the way SOAP and the various WS-* technologies achieve protocol independence is by basically ignoring the capabilities of the Web (i.e. HTTP and URIs) and re-inventing them in various WS-* specifications. This leads to a lot of unnecessary complexity and layering when you are already using HTTP as the transport protocol (i.e. the most common usage of SOAP).

On the flip side, there is something to be said for being able to use one distributed application model and support multiple protocols. For example, if you read the Windows Communication Foundation whitepaper you'll see it mentioned that WCF supports sending messages via HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ). I've actually been working on using this functionality in some of our internal Windows Live platform services since the performance benefits of using TCP for communications over SOAP/HTTP are considerable. However we'll still have SOAP/HTTP end points since that is the lowest common denominator that SOAP-based services that interact with our services understand. In addition, I'd like to see some straight up PlainOldXml/HTTP or RESTful end points as well.

One of the main problems we've faced in our evaluation of moving to multiprotocol SOAP services is how much of a leaky abstraction the "protocol independent" nature of SOAP tends to be in real life. My favorite issue thus far is that we actually use HTTP redirects in our current SOAP web services. Guess what? There is no "protocol independent" WS-Redirect specification. So we have to roll our own solution for non-HTTP protocols.

We've hit a couple of other minor issues but in general the support we've gotten from Omri, Doug Purdy and others on the WCF team has been great. In fact, I've started to lose some of my skepticism about the WS-* family of technologies. I still think they are overkill for the Web though. ;)