I've been reading about the SOAP vs. REST-debate for years now and most of it seems quite pointless to me: there are clear cases where SOAP is useful and others where REST is preferable. In fact, I've had this experience recently when writing a tool that aggregated results using the several Websearch APIs. Yahoo! has a REST API and Google a SOAP API. To get results from Google, you basically run wsdl.exe on their GoogleSearch.wsdl-file and before you know it (approximately three lines of code) you've got a reference to a handy array of ResultElement-objects that store all the info you would ever want to have about a searchresult (or well, that they'll give you anyway).
Excellent right? Because in contrast, when you want to do the same thing using the recently released Yahoo! API, you have to concatenate a bunch of parameters to a URL, run the HTTP request (WebRequest/WebResponse for instance) and parse the resulting XML-file. For instance with XmlDocument or some XmlReader. This will probably involve a case/switch-like piece of code unless you choose to do something a little more funky like deserialize it to an object.
In my experience however, if you want to integrate these services in a piece of software, you probably want the results to have a common interface, derive from a baseclass or adhere to some usage pattern. To get this to work with the Google API, you end up wrapping the generated code (you could, ofcourse, ignore the generated code or modify it so you end up with the output you like, but it's less work to just wrap it) and with Yahoo!, you came up with the classes you write results to yourself so you don't have to do anything at all. (Unless you use the code-first-design-later-methodology, which is still disturbingly common nowadays - I use it myself on my fun projects and it always pisses me off afterwards.)
In the end REST and SOAP get you the same amount of work, although the Google code will looke more messy, since you have multiple classes containing the same data (unless you really do discard the generated code, but that will mean a lot more work than wrapping it) and the Yahoo! code you wrote will be very much generic and reusable for other REST APIs.
Still, I see the point of SOAP: in a lot of cases, datatypes are crucial and you have all kinds of legacy systems in the back-end that you want to interface with unambiguously. So everything you write down in the WSDL definition is basically set in stone afterwards. Excellent! But for everything else, REST seems to be the way to go.