The web services exposed by Amazon.com are undoubtedly among the more successful examples of publicly accessible web services.
Amazon provide both a SOAP and a REST (or pseudo-REST) interface to their API, which means that a great number of client platforms (and developer preferences) catered for. It also provides a fun arena for developer religious wars :-).
Tim O'Reilly reported back in 2003 that 85% of the Amazon API access was via the RESTful interface. I have no idea whether that is still the case (I suspect there may have been some increase in SOAP use by Java developers owing to improvements in platform support, but I expect that to be offset by more .NET developers using the REST approach, for reasons I'll give below) - however I do know that it has little to do with the intrinsic merits of SOAP or developer acceptance of it.
I'm pretty confident that most .NET developers on approaching the Amazon API would have gone straight to the WSDL, generated themselves a proxy, and proceeded from there. And if you're designing an application for Windows or a mobile device, that's a reasonable thing to do. You have easy programmatic access, and you get back a nice strongly-typed response. Databinding the returned objects was a bit of a problem owing to the lack of properties to bind to (I suspect that problem may have gone away with .NET 2, but I'll need to experiment), but still, working with the API this way seemed the natural thing to do.
However, the truth is that a great number (probably the majority) of applications that use the Amazon API are web applications. If they are returning content to be displayed on the screen, the simplest way to return that content is actually as an XML document that can be transformed to HTML by an XSLT stylesheet (or you can use one of the Amazon stylesheets if you don't want a lot of control over the output). XML in that case is a better choice, which means that for the average suck-something-out-of-Amazon-and-stick-it-on-a-web-page scenario, REST is a more logical choice, because it actually saves you a lot of work (unless you don't like XSLT).
This is completely different from the reason I assume hardly anybody (if that) uses the SOAP version of the Flickr API: in that case it's simply because Flickr does not, as far as I can tell (and I'm not alone in this), provide a WSDL file...so unless you want to create your own (gee, that's sooo much fun), you can forget about generating a proxy - and let's face it, using SOAP without one is only marginally less horrible than working with XML-RPC.