The prevailing wisdom in webservices/web requests in general is to design your api such that you use as few requests as possible, and that each request returns therefore as much data as is needed
In database design, the accepted wisdom is to design your queries to minimise size over the network, as opposed to minimizing the number of queries.
They are both remote calls, so what gives?
Web service. You miss one thing - SQL always said get as little data AS NEEDED and make as many requests as you have to - not "dump your reqwuests down into mino bits".
Also, remote means additional latency. SQL / WS, all the same. Latency is EVIL. Cut down on round trips as much as you can, especially if those cost yu 20-30 times as much as in a LAN (<1ms vs. what - 30ms to 150ms in a remote scenario).
Probably because the fixed overhead for a web service call (made over the internet) is much higher than the fixed cost of a call to the database (typically over gigabit ethernet or even to the local machine)
Still, I would argue that you always want to reduce trips to the database to as few as necessary. The overhead is lower, but relative to most other operations your program does, it is still quite high.