If your organization is using a G Suite account, an add-on can be installed "domain wide" by the domain administrator.
To find out who your domain administrator is, use the following link:
https://support.google.com/a/answer/6208960
There is a difference between domain wide installation, and an individual installing an add-on in their user account.
For the add-on to be installed domain wide, the domain administrator must be signed in, and install the add-on as the domain administrator. First the domain administrator must open the admin console.
To log into the G Suite admin home page use the link:
https://admin.google.com/AdminHome
The administrator must navigate to the G Suite Marketplace, find the add-on, and install it.
Before an add-on can be installed, the Administrator must either enable Google add-ons from the G Suite Marketplace, or whitelist a specific add-on if you don't want to allow all add-ons to be installed.
Allow add-ons to be installed:
Navigate from the admin home page:
- Apps
- G Suite
- Drive and Docs
- Features and Applications
- Add Ons
- Turn ON
WHITELIST:
A specific Add-on can be whitelisted if add-on installation has been restricted in general. In order to whitelist an add-on the administrator will need the App ID of the add-on script. The App ID of a script must be provided by the owner of the script.
Note that the instructions provided here for domain wide installation, assume that the add-on is already published to the G Suite Marketplace. Getting an add-on verified and approved for the G Suite Marketplace is explained in the documentation.
Apply to Publish
Install Marketplace Apps
Control User Installation of Marketplace Apps
An alternative to an add-on is a library:
The users who want to use the library need to do some installation. They would need to open the Apps Script code editor from the spreadsheet, and enter the library key.
Documentation - Library
NOTE:
The Apps Script API can be used to create new project (script) files and overwrite existing project files. But the problem is, that the script would need to be bound to the Sheet, and there is no current way to programmatically get the script ID of projects bound to Sheets. (If this changes, and you notice, then make a comment to update the answer) If you know the project ID that is bound to the Sheet, then you could use the Apps Script API to overwrite the script file, or you could programatically update the library version number in the project file's appsscript.json file. That would provide a way to deploy bound scripts to Sheet's files, or update library version numbers. You could manually get and save which script IDs were bound to what Sheets files, and then use the Apps Script API to overwrite the project file. The user would either need to create a script that was bound to the Sheet, and then provide the project file ID, or the user could copy a template Sheet's file with a script bound to it.