In the normal course of things, there is no difference for workstation permissions between an account in the Domain Admins group and a Domain User account that has been added to the local Administrators group. Windows implements Domain Admin permissions primarily by placing the Domain Admins group in the local Administrators group at the time a machine is joined to the domain, so it amounts to the exact same thing from the point of view of a single workstation. You can see this by viewing the local Administrators group on a domain-joined workstation, and noting that the Domain Admins group is present as a member. The Domain Admins group has additional privileges when working on the domain itself, plus the benefit of being a member of the local Administrators group by default on all workstation in the domain, but from the point of view of a single workstation, and things that can be done on/to that workstation, there is no difference at all. Also remember that this is just the "normal course of things"; you can configure your domain or a workstation so that things are different.
This means that by default the Domain Admins user should still need to pass a UAC prompt to install your app. That you did not see one indicates that you no longer have a "vanilla domain environment", and someone deliberately disabled this on your domain... probably through group policy. This is a bad idea. You should see about getting that turned back on. The difference here between that and your normal user with admin rights is that someone took the time to turn off UAC. IIRC, disabling UAC is also a per-account (really: per profile) feature, and so this may even be something that you had to do for your own account.
The question now is how to work around this, to allow your local-Administrator Domain Users to install your software. To that end, it's important to remember how administrative accounts work by default in Windows now. Things have changed since Windows XP. Starting with Vista, and including Windows 7 and 8, you never have administrator rights by default, even if you're in the Administrators group, and sometimes even if you pass a UAC prompt. If you really want to use your administrator privileges in Windows Vista and later, you need to right-click the application or installer and select the
Run as Administrator option. Doing this will likely allow your Domain User accounts to install the program successfully, such that any user on the workstation can use the Add-In.
In this particular case, you may also be able to get around the issue by changing some file system permissions on the location where the app installed. By default, standard users do not have any write access inside the Programs Files folder where your add-in is likely installed. You may be able to fix your issue by finding the app's folder and setting permissions on that folder so that standard users will have write access. However, because we are dealing with an Office Add-In I suspect the problem is more likely to be write access to a registry key, or missing write access at install time such that an expected registry key is now missing. If that is the case, a work-around fix such as this may still be possible, but will be a lot more difficult to figure out and implement.