For any developer with limited resources, this means a library (where viable) can provide the same functionality to the user, at a lower cost to the developer than a service.
Usually, the centralization of these administration costs is cited as a benefit of services. People say, "services are easy because you can upgrade them centrally, so you can avoid slow-to-upgrade users making everyone's lives worse."
But this assumes that slow-to-upgrade users can have negative effects on everyone else. If one user can't have a negative impact on other users, then you don't care if some users are slow to upgrade; they're only hurting themselves.
You can prevent users from negatively impacting other users by not sharing state or resources between users; in other words, by avoiding services.
For example, a common scenario is a developer creating a library and a service together, and later discovering that the (now already deployed) library has some bug or incompatibility, and needs to be upgraded everywhere before the service can be improved. A big headache, which might naively suggest that functionality should be moved from the library to the service so that it can be more easily upgraded.
But if you didn't have the service in the first place - if there was only the library, containing all the functions, doing whatever the service was supposed to do in the first place - you wouldn't have this problem. Users who don't upgrade would suffer whatever problem exists in the initial version of the library, and everyone else would be fine.
Avoiding services completely in this way isn't always possible; but it's possible more often than people think. Some ideas along these lines to consider:
However, with some thought, often we actually can safely give users access to those resources, and so a library can work fine. Many resources don't actually need to be multiplexed by yet another service, perhaps because they're one or more of:
If user code is running on a sufficiently advanced platform, one not administered by the user, then a library can safely manipulate resources that aren't accessible to the rest of the program. For example:
But this is also possible with a library. Indeed, a library is strictly more powerful here; there's no reason you can't use those same protocols for a local library, and enjoy the same compatibility benefits.
These days, dynamic linking is often criticized, for the same reasons upgrading a service without involving your users at all is criticized, so consider carefully whether you want to do it. If you're fully avoiding services, such upgrades won't be necessary.
By avoiding the maintenance and upgrade costs of a service, a library can afford to contain more functionality. That's good for both the developer and the user.