Results that are not raster-based are not easily extracted through OGC API - Coverages
Coverages and OGC API - Coverages is not limited to gridded (raster) data.
For example point clouds are also coverages, and a point cloud encoded as LAS/LAZ response is a possible response.
Technically, a collection of features with properties is also a valid representation of a coverage. Although one could also negotiate an application/geo+json representation of /coverage, an OGC API - Features access mechanism (/items) might make more sense if the data is better accessed as a feature collection, with easy access to individual items at /items/{itemId} (though this could also be selected with Coverages - Part 2: Filtering with a filter=id={itemId} query parameter).
From Testbed 19 GDC ER Critical Feedback:
Coverages and OGC API - Coverages is not limited to gridded (raster) data. For example point clouds are also coverages, and a point cloud encoded as LAS/LAZ response is a possible response.
Technically, a collection of features with properties is also a valid representation of a coverage. Although one could also negotiate an
application/geo+jsonrepresentation of/coverage, an OGC API - Features access mechanism (/items) might make more sense if the data is better accessed as a feature collection, with easy access to individual items at/items/{itemId}(though this could also be selected with Coverages - Part 2: Filtering with afilter=id={itemId}query parameter).The OGC API - Common framework (including Part 2's collections) and OGC API - Processes (including the workflows and input/output), allow multiple access mechanisms and would work equally well with both OGC API - Coverages and OGC API - Features.
Perhaps it should be clarified to what extent feature collections as inputs/outputs are within scope of the GDC API.
But it would always be valid to extend a GeoDataCube API with capabilities defined in additional OGC APIs (e.g., OGC API - Features, EDR (#3)).