I have been watching with some amusement the reason "SOAP considered DEAD" articles. I think Bill de hOra made a superb analysis, but would also point people at Stefan Tilkov's perspective. I think they are both right.

1. SOAP has not taken off for non-enterprise uses. Its too complex, too stack-centric, and doesn't offer the immediate value of REST. And its harder to debug, which really matters. REST, you point your browser at a URL, get some results you can look at. SOAP, you need third party monitors(like the excellent SOAPScope), which you put between your app and the endpoint, and try and work out what is happening.
2. The continued presence of XMLRPC in internet apps shows that there is value in RPC-ish comms, but that SOAP is overkill for the limited actions of blog commenting and the like. For all I disliked about using XMLRPC, somebody competent (not me :) can write support for it in a day. Leaving you time to tune the perfomance to levels way beyond what SOAP stacks can do.
3. Some of the WS-* extensions to SOAP only make sense in the Enterprise and B2B "extended enterprise" areas. WS-Security, WS-Transaction. These things are orthogonal to the actual message, and add features that REST does not yet support. REST doesn't need WS-Security, because HTTPS does that. WS-TX is a different matter, but an equivalent is possible, I suppose.
4. Neither side does notifications very well. REST can do it trivially only if both endpoints are visible; WS-* is a morass of overweight specs in the area, all of unknown maturity/stability.
5. If you want through-firewall callbacks, today, XMPP, the Jabber protocol, is the only one that makes sense.
6. WSDL sucks, XSD has the sucky nature too. But imagine SOAP done with RNG and SSDL. The latter is the Newcastle Faction's alternative. After killing OGSI, they are turning the light of sensibility on the core WS specs. Go Savas! Go Jim!
7. REST has a cleary story for binary data. SOAP ignored it, had multiple competing add-ons, and now has a new 'blessed' solution that will take a long time to be available. REST treats binary just like anything else.

The best part of SOAP has to be the orthogonal header mechanism. The worst part has to be how today's stacks try and map the message to and from native classes, hiding the message from the caller. We need to do something about that. Indigo, stays in the native zone, but its interface definition language adds more SOAP-centric features. NetKernel 2.x lets you tell the runtime that any URL+{XSD,RNG} type is a SOAP endpoint, it generates the relevant (minimal) WSDL for you and then leaves your handler to deal with the incoming XML. Axis2 is moving away from making java-XML binding the centre of its architecture. And Alpine, my proposed Java SOAP stack would leave users to fend for themselves with a XOM or JDOM datastructure. That is, to make SOAP succeed, we have to abandon the central feature of today's stacks "XML messaging without you seeing the XML", and move to "XML messaging". To survive, SOAP is becoming more RESTy.

The problem is, such a U-turn needs to deal with the installed base, meaning your callers are still stuck in the old vision of "give us your classes, we introspect to generate the messages". Even if you implement the best next-generation SOAP service, your caller's code may still be way too inflexible. That is, they may be the wrong implementation architecture for next generation enterprise systems, regardless of the relative merits of the protocols.

One point I want to make is observe that if SOAP does survive, in the "niches" of enterprise and grid (WSRF) apps, it is a far cry from the original vision. The vision there was that SOAP was the way to write "Internet applications", which is why they are called Web Services. It was meant to be the ubiquitous protocol for everything; it is failing in this task, and is surviving by pursuing the high ground of what is essentially distributed-objects-over-XML.

There is no Simple in SOAP any more, there is no Web in SOAP Web Services.