One request, many possible combinations of data
A traditional REST endpoint typically returns a predictable, fixed shape of data, which makes an endpoint-level authorization check — can this caller hit this endpoint at all — a reasonably sufficient gate in many cases. A flexible query interface breaks that assumption deliberately: a single request can ask for any combination of fields across related data, which means the permission question can't be fully answered by checking whether the request is allowed to happen at all.
The correct granularity is the individual field: a caller might be permitted to see most of what a query requests while one specific field mixed in among the rest should be withheld. An endpoint-level check has no way to make that distinction, because from its perspective there's only one request, not many individually-checkable pieces.
The over-fetching failure mode
Because a flexible query's shape is driven by the caller, it's easy for a query to structurally pull in more than the caller specifically needed — a functional inefficiency most of the time, but an authorization gap the moment the extra data included is something the requester wasn't meant to see. Field-level checks that run independently of what else the query happens to request are what actually close this — relying on the query's structure to imply what's appropriate leaves exactly this gap open.