Sanjiva defends the value of SOAP against REST. His argument is that by adding extra stuff in the headers, you get tamper proof end to end messaging (WS-Security, and reliability (WS-Reliable Messaging).

But what do you lose?

1. The ability to return binary data like a JPEG, except as an attachment (bypasses the tamperproofness) or via MTOM (not proper XML). That means that I cannot put a SOAP URL in the web browser and expect to see an image back
2. The ability to put SOAP URLs in the browser. That is, if your endpoint relies on WS-Addressing and has complex XML content to describe what it is you are messaging
3. Debuggability. See (1) and (2) above. Yes, I know about debugging proxy servers, but have you ever tried to chain them together to debug something beyond the firewall. I think mindreef do this, but the others (Axis tcpmon, PocketSOAP) don't. I am working at home today, partly because I'm lecturing at the university this afternoon, but mainly because I need to debug interop with a third party endpoint, with no proxy server in the way.
4. The ability to ignore long-standing defects in SOAP stacks. Simon Fell has to deal with the .NET stack putting a null byte in a UTF-8 message, which is just plain illegal XML.
5. The ability to return useful HTTP error codes other than 500 and 302. Now, SOAPFaults themselves are very nice (more on that), but there is no equivalent of a 310 redirect-to-another-page. And although WS-I say that stacks may use that, so few do, you cannot rely on it
6. The ability to interop with anything that doesn't have a SOAP stack. POX+HTTP is far more common, not just .NET/Java/C++ but Perl, Python, JavaScript, SWI Prolog, Ant, shell scripts (by way of wget and the like). I know about the various javascript to SOAP bridges, but few are mainstream, or built into the browser.
7. The ability to send nice XML messages, ones that are easy for humans to work with. XML messages that are generated by contract last tools are pretty nasty. If you write a good XML schema you can have nice payloads, but the mainstream stacks often have a real hard time working with them. And we all know that the SOAP stack teams hate bugreps related to hand-written WSDL, don't we?
8. The ability to directly write your schemas in anything other than XmlSchema, which as everyone knows, sucks. You could use RelaxNG and have it converted to XSD, but you will still end up staring at the XSD when a SOAP stack starts complaining about the XSD-to-source conversion, and maybe even have to make changes. Working in the XSD space is the only way to stay on top of this.

Now, by embracing HTTP/POX (sounds like a disease), what do you lose?

1. The ability for developers who don't want to work with XML from using your application, unless you provide the client-side API for them.
2. SOAPFaults. Design errors in JAX-RPC/JAX-WS notwithstanding, I love SOAPFaults. Why? Diagnosis. Axis1 gives you a stack trace and a hostname, even the nested HTTP error code. Alpine, well, Alpine lets any any Java throwable that implements Element getFault() to make up its own SOAPFault, so the runtime itself doesn't get confused with marshalling Ws-BaseFault faults; that's left to the WsBaseFault class.
3. A machine readable language that specifies interactions. WSDL is not human readable, and so error prone that neither SOAP stacks or SOAP developers seem to get the hang of it. But the idea was nice: a language to describe communications. Pity about the implementation details .
4. Good implementations of client and server from Apache, Microsoft, Simon Fell, and others.
5. Integration with architectures and organisations that believe in WS-*

The latter is the real issue. The best argument for going with WS-* is not technical, far from it. It's political. And that can change.