The GET model is acceptable for data access (unless you want to radically reduce round trips -- one answer to this is to "virtualize" the REST model and let an app ask for N chunks of data in one request) however, it's bad for data updates, where you're better off exposing operations that exposing data directly.
Security, for instance, is easier to implement if you expose operations because security rules most frequently govern state transitions: to apply security rules in purist REST, you're always having to write comparisons between the old state and the new state and you've got to test for every single possible thing that could break security, even combinations of things that would be harmless by themselves.
If a security-sensitive operation is exposed as an operation, the implementation of security rules is much more clear.
Ah, I was referring to caching requests from the webapp producing the web page to the remote services it's consuming, assuming this was the setup - not browser caching.
Unless we're using the same words to mean different things, I don't see how you could interact with an API method with understanding what you are passing to or receiving from it at a certain level.
On the other hand, one of the large selling points of REST-style design is the ability to know how to interact with resource URLs using common http verbs without necessarily knowing what that URL represents - for example, GET or POST have the same meaning throughout the API.
I don't think the question of transaction boundaries and REST design are mutually exclusive. One can build a REST system that uses meaningful transactions around it's operations - the obvious solution is to make the operations that are exposed the same as what you want to wrap transactions about, and only expose these operations. In fact I find it strange that some might think these are two exclusive concepts.
The other problem you describe sounds like it would be easily solved with client-side caching. REST and caching remote operations are not exclusive of one another either. HTTP provides a very natural way to control caching. Having to make 100 network round trips for the same resource should be unnecessary in any system, REST or not.