Ilyaが引用しているMasonBendixenのブログ記事は正しいです。RCWはプロセスではなくAppDomainにスコープされています。Runtime Callable Wrapper（MSDN 2.0）の記事が「カジュアルに」話していたと推測できます。単一のAppDomainのみを使用して実行するのが最も一般的であるため、その記事は一般的な意味で必ずしも正しくありませんが、その文は技術的に正確ではありません。
あなたの特定の質問に関して：
「カウントが0に達するまでループでMarshal.ReleaseComObject（x）を使用するとどうなるか知りたいです（推奨）。他のアドイン（同じOutlookプロセスの他のアプリケーションドメインで実行されている）からの参照を解放しますか？ ？」
これに対する答えは、アドインの設定方法によって異なります。一般に、予防策を講じない場合、答えは「はい」です。同じAppDomain内で動作する他のアドインの参照に影響を与えます。ただし、別のAppDomainから実行していると述べているので、そうではありません。
アドインを分離するために使用できるCOMShimWizardバージョン2.3.1があります。COM Shim Wizardのドキュメントは、次の場所にあります。COMShimWizardバージョン2.3.1を使用したMicrosoftOffice拡張機能の分離。
COM Shim Wizardは、リフレクションを使用して、別のAppDomain内にアドインアセンブリをロードするカスタマイズされたCOMフロントエンドローダーを構築します。これにより、2つの点で安全性が生まれます。
（1）個別のカスタマイズされたCOMエントリポイントを使用することにより、アドインはMicrosoftOfficeによって他のすべてのアドインとは別に正しく識別されます。それ以外の場合、デフォルトでは、すべてのアドインが同じデフォルトのmscoree.dllローダーを共有します。同じローダーを共有する場合の問題は、アドインにクラッシュが発生した場合、mscoree.dllがMicrosoft Officeによって問題の原因として識別され、次回は自動的に読み込まれないことです。手動で再度オンにすることはできますが、他の誰かのアドインに問題があるため、次回はアドインが自動的に読み込まれません。
（2）アセンブリを別のAppDomain内にロードすることにより、ランタイム呼び出し可能ラッパー（RCW）は、同じプロセスにロードされる他のアドインから分離されます。この場合、Marshal.ReleaseComObject（object）またはMarshal.FinalReleaseComObject（object）を呼び出すと、他の人のアドインに影響を与えることはありません。さらに重要なことに、これらの他のアドインのいずれかがそのような呼び出しを行う場合、アドインは破損から保護されます。:-)
COM Shim Wizardを使用することの欠点は、別のAppDomainから操作することにより、余分なマーシャリングのオーバーヘッドが発生することです。これは、MicrosoftOutlookアドインでは目立たないと思います。ただし、Microsoft Excelアドインの場合など、オブジェクトモデルへの呼び出しが多い一部の集中的なルーチンでは、これが要因になる可能性があります。
別のAppDomainからアドインをすでに実行しているとのことです。これが当てはまる場合は、他のAppDomainに関してMarshal.ReleaseComObject（object）およびMarshal.FinalReleaseComObject（object）呼び出しからすでに分離されています。（ちなみに、これをどのように行っているのか興味があります...独自のAppDomainを明示的に作成していますか？Visual Studioの既定のアドインテンプレートは、個別のAppDomainで実行されず、mscoree.dllを使用して読み込まれます。）
独自のAppDomainを作成している場合、コードは分離されていますが、他の手段を利用しない限り、アドインはデフォルトのmscoree.dllローダーを共有しているため、そのIDは他のアドインから分離されていない可能性があります。これに対処します。
これがお役に立てば幸いです...