It's named separation of concerns. The example takes the principle beyone the scope of the classes and objects.
A vague description of the components could be:
Data API is meant to be what we know as DAO.
API app is where the domain model and the business runs at (or part of it), and it's exposed via API web.
These kind of apps might integrate more servicies. That's why they are known as middleware.
The given example illustrate the sort of architecture it's expect to be deployed in the cloud. Microservices.
Maybe, the example is too simple and both components (APIs) seem to do the very same thing, but the differences lie on their respective responsabilities (as part of a whole).
why not just connect the DB directly to the API app your external apps
are going to be using?
You could indeed. It's up to you. It's your needs, your requirements, your design. In the case of the example doesn't matter. The system is very simple.
However, in more complex systems, you may suffer what we know as coupling. Not the one between classes. The one between apps/services.
The example is trying to be as simple, complete and suitable to the context (cloud) as possible.