Andrew Cherry [MSFT]
The HKLM/HKCU distinction actually causes some complications, and was designed the way it was for a reason. Just switching to registering in HKLM is actually somewhat ill-advised.
HKLM was intended to hold system-wide, admin-mandated COM Add-ins. Hence, in Office 2003 and previous, the COM Add-Ins dialog doesn't display the Add-Ins loaded by that key -- both to prevent casual users from disabling required Add-ins, and to restrict attempts to modify the HKLM key that non-administrators should not have access to. If you're logged on as an administrator, actually, you should be able to see the HKEY_LOCAL_MACHINE specified add-ins.
HKCU was always intended to hold the add-ins intended to be controlled by the user. In Office 2007, the decision was made to display all Add-in entries in the COM Add-ins dialog (group policy constrained); however, without appropriate system permissions, an end user would still be unable to turn off HKLM-specified Add-ins. In order to move further into the direction of permitting user-based applications, rather than system-wide changes, the new Office 2007 will only load VSTO 2005 SE solutions that have been registered in HKEY_CURRENT_USER -- entries in HKEY_LOCAL_MACHINE will not be loaded. In Office 2003 (using VSTO), the solution will still be loaded, but this isn't supported moving forward.
The preferred mechanism is to install the Add-in into HKCU; Group Policy can push your MSI down for every individual in an enterprise-scale solution regardless of system, and the question of whether you should force every user on a given machine to run your add-in comes into play on the smaller scale -- particularly given that they won't necessarily have the ability to uninstall the add-in.
Thanks,
Andrew Cherry