I worry the author is bluring Capabilites and Serverless Environments
My team differentiates between a Serverless Environment and a Capability/Service that may or may not be delivered from a Serverless Environment.
My reading of this article is that the author is describing the ability to build and offer Capabilities behind an API but there is nothing abut his descriptions that means the people offering them have to be using or benefiting from a Serverless Environment. The whole point of a Capability is that it is a black box to any other application using it, so they should not know or care what is happening under the hood.
For us a Serverless Environment is something that AWS/Azure offer us to deploy code into alongside Capabilities they offer such as a DB or Storage. We are able to deploy our code behind an end point without any concern for the underlying infrastructure that the code is running on. We know that within the limits we are paying for, each time that end point is hit our code is executed and the environment our code is in is surge resistant, resilient and scalable while still only costing us what we use.
The key element for us that makes what we are building as a dev team Serverless is that the degree of abstraction between our code and the environment we are running our code in is so great that it is no longer something we need to maintain or spend much time concerning ourselves with.
The cost of this simplicity is a significant degree of lock-in where our code is developed and optimised for the Serverless Environment we are building for. This makes each Capability we build in it pretty sticky. However the lock-in is only at a Capability level. Each Capability is a black box to the others in our solution so we can migrate some or all of our Capabilities between different environments fairly painlessly as and when our business case justifies it, running two in parallel until we are comfortable shutting down the one we are moving from (given pricing we often can just stop using the original one, leaving it there should it be needed).