The usual answer from your lawyer applies here, too: It depends.
If you can write your own plugin or web service, things may be different than the average user, who uses it.
The web service
The web service provides functionality over a network (usual Internet). It runs on someone else's computer who takes care about keeping it working with redundancy, load balancing and security threads. Your access to the service depends on the quality of your own network connection and the service is usually not available while being offline or without connectivity on the go in rural areas.
You may need to prepare for service being not available and have a table in your database for jobs, so when service is not available, you can store requests and process them later.
If the service gets new features, those are usually rolled out quickly. Usually first to a tester group, but over time to all users. A good service will not break functionality, but use versioning in the URLs to keep old versions running.
Your access to the service will be available as long as you pay whatever the service vendor wants to charge you. Per request, per time and with arbitrary usage limits. The service may stop being available for you if your credit card expires and you forget to update it. If the company goes out of business or decides the service is not profitable, the service may shut down with very short notice.
One question is who owns the data. Can the service provider use data you provide and for example use it for advertisement. Servers may be in a different jurisdiction and could be seized. Problematic if you use shared servers and some other customers does something illegal and your data is seized with the one of the suspect.
Finally you need to consider how big the impact is on you, in case the provider is hacked and all your data on the server is copied by the hackers. Or worse, if the hackers can read all data coming back over months. Of course you may have a contract stating how data is processed, stored, secured, backed up and shared.
The library (or plugin) providing a service locally within your solution is a bit different. You get the library and you can use it locally, even offline. There is usually no per-use fee, but only a license fee to get the library once, with possible yearly maintenance cost.
A shared library has access to the hosting application, so it can work with windows and controls. It can show own dialogs within the application and provide additional functionality on the host windows.
If the vendor of the library goes out of business, the library will usually continue to work. Over time some functionality may break, e.g. with an update to the operation system. If that happens, you may look for other libraries to provide such functionality and gradually replace features as needed.
Every request can be answered by the library instantly or after some processing time. The network latency has no effect. All data can be accessed within the same memory and same disk space as no data needs to be uploaded. Performance may be higher compared to a service, as the library is usually provided as compiled code for the local CPU. And of course all data stays locally.
Finally the library may help you to access a web service. We have examples for e.g. sending emails, Amazon S3 upload/download and more for MBS Plugins.
What you prefer to use depends on your concrete task to solve. Think a little bit about all those factors above and decide wisely. If you have a library doing the job or you already pay for the service, you may just use that. Otherwise it is a calculation of make vs buy, pay by month for a service vs. pay one time for a license and how much work the implementation and future maintenance is.