I'd say the adoption of HTTP protocols was certainly driven by firewalls. This was just as true for SOAP as it was REST. However, in earlier times caching was also important, and this is one of the places where REST beat SOAP. However, the caching idea seems to have been lost by most developers now.

For high volume sites we would cache at multiple levels. At the load balancer, on the CDN or in the browser - depending on how public/user-centric the data was. You would not expect a browser to return to the server every time for a 1 pixel spacer gif (oh the glory days), and you wouldn't expect it to keep retriving the user's name for the top of each otherwise static page.

However, things changed - the consumers of APIs were no longer browsers and the internet just got faster and faster. I can understand why developers just decided to forget about caching.

This is probably why most developers I now encounter just can't understand why the thing at the end of a GET or PUT url should be a "thing" not an operation.