The benefits of microservices aren't architectural. The point re. library APIs vs services APIs is completely correct, because that's actually not what the microservice style addresses.
The point is rather organizational/operational - Being able to independently deploy, scale, monitor and manage different parts of the system.
That allows you to distribute ownership of the system, and also allows partitioning, so that a failure in one component need not effect the whole system.
When I say 'architectural' there I mean that as in the underlying design. How the system is modeled and and what different objects and interfaces exist in that model.
Eg. Say you have a billing component in your system. You may have the same underlying billing component in either a monolith or as microservices. It may be a nicely decoupled in both cases (either existing as an independent module/library in the monolith case, or as an independent service in the microservices case.)
The (potential) benefit that's afforded from the microservices approach is not that there's a better underlying design there, but that a single team or developer can properly take ownership of deploying, scaling, monitoring and managing the service, independently of the rest of the application. (Plus scope for partitioning and graceful partial failures vs whole system failures)
The point is rather organizational/operational - Being able to independently deploy, scale, monitor and manage different parts of the system.
That allows you to distribute ownership of the system, and also allows partitioning, so that a failure in one component need not effect the whole system.