Most of the applications I write are server-side C# or Java, or desktop applications in WinForms or WPF. These applications tend to need a richer service API than REST can provide. Plus, I don't want to spend any more than a couple minutes creating my web service client. The WSDL processing client generation tools allow me to implement my client and move on to adding business value.
Now, if I were writing a web service explicitly for some javascript ajax calls, it'd probably be in REST; just for the sake knowing the client technology and leveraging JSON. In my opinion, web service APIs used from javascript probably shouldn't be very complex, as that type of complexity seems to be better handled server-side.
With that said, there some SOAP clients for javascript; I know jQuery has one. Thus, SOAP can be leveraged from javascript; just not as nicely as a REST service returning JSON strings. So if I had a web service that I wanted to be complex enough that it was flexible for an arbitrary number of client technologies and uses, I'd go with SOAP.
