I think they’re saying that you can expose your lower-level atomic APIs as serverless functions, and then, separately, build a “routing and aggregation layer” that exposes APIs that people might actually want to use. And that, for a lot of projects, that routing/aggregation can be entirely specified in a declarative manifest format, rather than involving any coding.

This neatly cleaves responsibility: your business logic team can just build+deploy+expose functions; and your frontend and ecosystem teams can build+deploy+expose the APIs they want on top, perhaps being maintained within their own codebases.

These can even be done on two entirely-separate platforms, rather than both being a part of the same “serverless” IaaS. You could use any combination of commodity FaaS providers (including your own hosted FaaS clusters) to deploy functions to; and then you could use some “smart” load-balancing system (e.g. Cloudflare Workers, or the routing component of an FaaS) to do the routing+aggregation on.