Even if you only need to change 3 or 4 lines of code, that's not generic enough to have your code refer to the library. The code needs to be totally generic in order to just "plug in" a new update and not manually make any code changes. App configuration settings need to be in a different place than the generic code. So, any app settings that a generic module needs shouldn't be in that generic code file. Separate out settings from generic code. Either put them is totally different files, or maybe put all the settings at the very top of the file. But even if you put the config settings at the top of the file, then you can't just copy over that file, because you might be copying one app settings over a different app. So, if those 3 or 4 lines of code that you need to change are app specific, then they should be somewhere else. You need to manually look at your app configuration settings for every app if there is a chance that they got changed.
Creating generic module files isn't necessarily directly related to when you'd use a library or not. It seems like you are considering a way to automate updates in order to avoid mindless copy and paste, time consuming work. If you want to be able to update a generic module to multiple target projects, and you use a library, then you'd need to either use the "head" version or you'd need to change the version number in the setting that is referencing the library. You wouldn't want to use the head version unless you had separate library files for development and production. If you used the head version, then any saved changes in the library would immediately be deployed to everywhere it was being used. That could be a disaster. Using the head version would avoid the need to update the library version number, but then you'd need to copy your development library file over the production library file. So, either way, there is work to be done to implement the update. If you wanted to avoid even the task of manually updating the version number. It
is possible to use the Apps Script API to programmatically update the appsscript.json / manifest file, which would automate the library version update process. But then you'll need to find/create some code to do that. Even the "professionals" may not have a totally automated way to update changes of generic modules to their production files in one click. This is an interesting subject, and I don't know of any public/popular app to totally automate App Script files to every place where some generic module is used.
I think that the real issue is automating updates, or making the code updating process as easy as possible. You might think that using a library would eliminate the need to keep a list of every project where that code was being used. But, if you need to update the library version number either in the manifest file, or go into the project manually, then you still need a list of every project where it's being used. You don't need to use a library to automate or programmatically update code, but you'd need to use the Apps Script API. So, the real help for taking a lot of the work out of updates is by using the Apps Script API to overwrite content in the target file.
Lot's of people use GitHub if they need to collaborate with other programmers on files, and there are ways to trigger updates from repositories. But again, I don't know of any complete, well explained system that incorporates all these possibilities.
Hopefully this has given you some information even if I haven't provided a fully automation solution for you.