That article covers developing add-ins for Visual Studio. It doesn’t relate to developing Office add-ins.

As I said above “The reaction to not releasing a COM reference depends on the implementation of the corresponding COM server.”

From today’s email, on results of releasing COM objects: “I had to refactor the code a little bit to load a TaskItem only when it is needed and release it shortly after but once all references to TaskItems were released the strange behavior disappeared. Who would have thought that the underlying COM implementation could be this tricky??”

Note that they discuss getting COM objects by two add-ins (for Visual Studio!); the add-ins are loaded into the same AppDomain (see Ian Griffiths’ remark). That is, their add-ins are non-isolated. You create a non-isolated Office add-in using the Shared Add-in template in the New Project dialog. However, not using non-isolated Office add-ins is a well-known practice. Say, at http://msdn.microsoft.com/en-us/library/aa159894(office.11).aspx they describe the need to use shims as follows:
Security. If you set the Office macro security level to High (or Very High in Office 2003), as is recommended, then Office examines the DLLs it loads for digital signatures. When you deploy a managed extension, the DLL that Office examines for signatures is always Mscoree.dll. This is the .NET common language runtime (CLR) engine, which in turn loads your custom managed extension DLL. The problem is that you cannot digitally sign Mscoree.dll. Therefore, you need to interpose a COM shim DLL, which you can sign, as the first DLL that Office examines for signatures.
Isolation. If you do not use a standard COM shim (such as the Visual Studio Tools for Office loader) or provide your own custom COM shim, your extension DLL loads into the default application domain along with all other un-shimmed extensions. All DLLs running in the same application domain are vulnerable to potential damage caused by any other DLL in the same application domain. Also, any un-shimmed add-in that crashes in a host application disables all other un-shimmed add-ins for that application.

One of the potential damages mentioned above is that an add-in may release a COM object used by another add-in; exactly the same scenario is discussed in the article you are referring to.

What about this article:

http://blogs.msdn.com/b/visualstudio/archive/2010/03/01/marshal-releasecomobject-considered-dangerous.aspx