Building software is about tradeoffs. Moving things into a services encapsulates functionality and allows separate teams of developers to work independently. For a new startup with two developers, it's overkill and will slow you down.
However, if your team is the size of LinkedIn's or Netflix's, you need this independence and factoring things into services can be a great way to do it.
It is unclear to me what the intended mechanism of services helping different teams work together is that is not also provided by just writing libraries. Could you elaborate?
For example, say we're on a team at Netflix responsible for handling recommendations. We could provide this to other teams a library they call: get_movie_recommendations(user, genre, ...)
However, that call will need to hit a datastore. Which datastore does it use ? Which servers is that datastore running on ? When we make changes to the schema and need to migrate, which groups do we need to involve ?
If it's a service, the recommendations team can own everything: the code, the data, and the servers. The other teams can be treated like customers of the service.
However, if your team is the size of LinkedIn's or Netflix's, you need this independence and factoring things into services can be a great way to do it.