Setting aside that functions are also APIs…this hits several of the hot architectural topics today: coupling vs. cohesion and monoliths vs. microservices.
In one of @klincecum’s Wiki posts, we talk about coupling and cohesion, so no need to repeat that here.
But monoliths (one big application) and microservices (many services) have been the latest topic in software architectural circles. The latest take is that, like coupling and cohesion, we need balance, and the current suggestion is to build a modular monolith to start with, then evolve the system for particular business capabilities as required. The key here is modularity.
This has the battle between Unix/Linux and Windows, CISC and RISC, and software architecture for years. Do you build small things that do one thing really well and assemble them as needed, or do you build specialty things that are optimized for one task but not easily changed? At least for now, Linux and ARM appear to be winning the day.
Companies like AWS, Google, and Microsoft are API-First organizations. This reduces coupling and allows them to react to changes and build new things quickly. At Microsoft, the API comes first. Next, they build a PowerShell script to interact with the API. Finally, they may add a UI. This provides automation out of the box but also a guided experience. Importantly, each piece is easily testable on its own and not only during end-to-end testing.
In the end, it’s all about balance. Do we need 37 BAQs or three? One Function Library or more? How much duplicate code do we want to manage if it’s in five single purpose function libraries? 
What is easier to manage and evolve?
That depends on the point I imagine. What is the point being defeated here?