There are multiple ways which this question can be answered:
Aggregation of endpoints
API Gateways mostly aggregate other endpoints, not necessarily their results. That is, it is a single server which might mirror other endpoints with some additional functionality, like authentication, or routing.
The point is to centralize some services, hide the actual servers from the outside network, etc.
Aggregation of results
If you really want to have business logic on the Gateway, pulling different documents together to another document, or just altering requests or responses, you might be looking at an Enterprise Service Bus.
Whether aggregation is good
This is of course debatable, and up to individual opinions. One might argue, that there is a reason we got (mostly) away from SOA/ESB type solutions. This reason might be because individual responsibilities were not clear and would tend to collect on the ESB side, leaving the endpoints "dumb". Eventually resulting in the ESB knowing everything.
The "REST" approach is different. It builds on "smart" endpoints, knowing their part, and making sure no other components need to know any of the details. This idea in itself seems to be in conflict with making the Gateway know more about the responses.
Indeed, there are some architecture ideas, like Self-Contained Systems, that build on the idea, that any function your client would need should be covered completely by a given endpoint. It should not need synchronous communication with others to fulfill a request in its own area of responsibility. This also suggests that aggregating results might be counterproductive.
As always though, it all depends on the exact requirements.