Client-API round trips matter, because the latency is very high. API-DB latency will be much lower, so the number of round trips there is less important. GraphQL allows you to query any nested structure in one Client-API round trip, but there may be many API-DB round trips per query.

It is better to have the resolver aggregate data, than to have multiple calls from the client to do it. The earliest uses of GraphQL was as a service aggregater. I'd be curious to know where you are seeing this "advice".

I've only used it to aggregate backend services rather than as an SQL query builder, and this is also how it's used at Facebook.

I'd have concerns about writing business logic in resolvers. If I was using it with a single SQL db I'd probably write a separate non-GraphQL layer for business logic and keep the resolvers thin.