以下リンク先に、マイクロソフトの説明があります。
Office のサーバーサイド オートメーションについて

開発者は Microsoft Office のオートメーションを使用して、Office 製品に組み込まれている能力や機能を使用するカスタムソリューションを構築できます。 このようなプログラムによる開発は、比較的簡単にクライアント システムに実装できますが、Microsoft Active Server Pages (ASP)、ASP.NET、DCOM、Windows NT サービスなどのサーバー側のコードから自動化が行われると、多くの問題が発生する可能性があります。

まずは問題が起きるか否かの話
クライアントだと問題はないが、サーバーでの実行は問題が発生する可能性ありと言っています

Microsoft Office のすべての現行バージョンは、クライアント ワークステーション上のエンドユーザー製品として実行されるように設計、テスト、および構成されました。 また、対話型デスクトップとユーザー プロファイルが想定されています。

対話型デスクトップとユーザープロファイルといっているので、ユーザーがログインしGUI上でユーザーが操作することを想定し、ダイアログ等が出た場合には対処できることが前提とされている。ユーザープロファイルを想定しているということは、サーバー上のようにログイン無しのバックグラウンド実行は想定していないことを暗に意味しています。そのことは次の行にはっきりと記されています

Microsoft では、無人の非対話型クライアント アプリケーションまたはコンポーネント (ASP、ASP.NET、DCOM、NT Services を含む) からの Microsoft Office アプリケーションの自動化は現在推奨されておらず、サポートされていません。この環境で Office を実行すると、Office が不安定な動作やデッドロックを発生する可能性があるためです。

推奨されていないとまで言っていますね

続いて、5つの問題について話が続きます。

ユーザー ID: オートメーションによって Office アプリケーションが起動する場合でも、アプリケーション実行時にユーザー ID が想定されています。 アプリケーションを起動したユーザーのユーザー レジストリ ハイブの設定に基づいて、ツールバー、メニュー、オプション、プリンター、一部のアドインの初期化が試行されます。 多くのサービスは、ユーザー プロファイルがないアカウント (SYSTEM アカウント、IWAM_[サービス名] アカウントなど) で実行されています。 そのため、Office が起動時に正しく初期化されないことがあります。 この場合、CreateObject 関数または CoCreateInstance 関数のエラーが Office から返されます。 Office アプリケーションを起動できても、ユーザー プロファイルが存在しない場合、他の関数が正常に動作しない可能性があります。

この件についてGPTに確認してみました

自分：この問題については、一度でも実行するアカウントでログインしてOfficeを扱ったのであれば、初期化はされているの認識であっていますか？またユーザープロファイルに依存するような関数を使っていなければ、この点については問題ないといえるか？

GPT：はい、あなたの理解はほぼ正しいです。以下、Microsoftの説明を技術的に整理しつつ、あなたの質問に回答します。
✅ 回答1：一度でもログインしてOfficeを扱ったアカウントなら、初期化は済んでいるか？
→ 原則として「はい」です。
・ Officeは、初回起動時にそのユーザーの**ユーザープロファイル（レジストリ、テンプレート、アドインの情報など）**を構成します。

・ そのため、一度でも対象アカウントでWindowsにインタラクティブにログインしてOfficeを起動していれば、そのユーザーのプロファイルは存在し、初期化も完了しています。

・ こうしたプロファイルがあることで、CreateObject や CoCreateInstance を使ってOfficeを起動する際にエラーが出にくくなります。

✅ 回答2：ユーザープロファイルに依存しない関数だけを使うなら問題ない？
→ 「ある程度までは」その通りですが、油断は禁物です。

Officeアプリケーション（特にExcelやWord）は、内部的に次のような処理でユーザープロファイルに依存する可能性があります：

・ 初期プリンタの取得

・ テンプレートファイル（Normal.dotmなど）の読み込み

・ アドインやレジストリ設定（セキュリティ設定など）の確認

・ UI要素（ツールバー、メニュー）の構成

もしあなたのバッチ処理が以下のような限定的な処理であれば、問題が起きる可能性はかなり低くなります：

・ Excelファイルの読み書き

・ セルの値の取得・設定

・ ファイルの保存や印刷指示（プリンタ依存に注意）

・ 複雑なマクロやアドイン、テンプレートを使用しない

プログラムを実行するアカウントでログインし、Office操作して初期化をすませたうえで、
ファイルの中身の読み書きぐらいだと可能性はかなり低いという言い方になっています。

次の問題が一番大きい気がします

デスクトップとの対話機能: Office アプリケーションは、対話型デスクトップで実行されることを想定しています。 状況によっては、特定のオートメーション機能が正常に動作するために、アプリケーションを可視化する必要があります。 予期しないエラーが発生した場合、または関数を完了するために不明なパラメーターが必要な場合、Office はモーダル ダイアログ ボックスを表示し、実行する動作をユーザーに確認するように設計されています。 対話型ではないデスクトップのモーダル ダイアログ ボックスを閉じることはできません。 そのため、そのスレッドは永久に応答しなくなります (ハングします)。 コーディング方法によってこの問題が発生する可能性を軽減できる場合もありますが、このような方法で問題全体を回避することはできません。 そのため、サーバーサイド環境から Office アプリケーションを実行することは危険であり、サポートされません。

ログインして人が操作することを想定しているので、場合によってはダイアログが表示されたり、ハングしてとまっているということを人が判断しとめたりそういったことを前提しているから、よくないという話ですね
これはさすがに自動化している以上、一定の時間がたつとプログラム側でエラーをはいて終了とかそういった対応を想定しておかないといけないとかそういう話になると思いますが、そもそもサポートしていないと念を押しています・・・。

次の問題

再入機能とスケーラビリティ: サーバーサイド コンポーネントは、複数のクライアントに対応するために最小限のオーバーヘッドで高いスループットを持つ、再入性が高いマルチスレッドの COM コンポーネントである必要があります。 Office アプリケーションは、ほぼすべての点でその反対のアプリケーションです。 Office アプリケーションは、再入機能がない STA ベースのオートメーション サーバーであり、1 つのクライアントに対して多様でリソースを大量に消費する機能を提供するように設計されています。 また、サーバーサイド ソリューションとしてのスケーラビリティをほとんど提供していません。 さらに、メモリなどの重要な要素に対して固定の制限があります。 これらの制限は構成で変更できません。 さらに重要な点は、Office アプリケーションが、メモリ マップ ファイル、グローバル アドインまたはテンプレート、共有オートメーション サーバーなどのグローバル リソースを使用していることです。 そのため、複数クライアント環境で Office アプリケーションが構成されると、同時に実行できるインスタンス数が制限され、競合条件が発生する可能性があります。 同時に複数インスタンスの Office アプリケーションを実行する予定の場合、開発者は、"プーリング" または Office アプリケーションへのアクセスをシリアル化して、デッドロックやデータ破損の可能性を回避することを検討する必要があります。

定時実行のバッチ処理等でマルチスレッドによる実行がなければこの話は問題ないことになります

次の問題

回復性と安定性: Office 2000、Office XP、Office 2003、Office 2007 では、Microsoft Windows インストーラー (MSI) テクノロジを使用して、エンド ユーザーのインストールと自己修復を容易にします。 MSI では、"初回使用時にインストールする" という概念が導入されています。 これにより、システムの実行時に機能を動的にインストールまたは構成したり、特定のユーザーに対してより頻繁に機能をインストールしたり構成したりできます。 サーバー側環境では、パフォーマンスが低下し、ユーザーにインストールの承認またはインストール ディスクの提供を求めるダイアログ ボックスが表示される可能性が高くなります。 これは、エンド ユーザー製品としての Office の回復性を高めるために設計されていますが、Office の MSI 機能の実装は、サーバー側環境では逆効果です。 さらに、この種類の使用のために設計またはテストされていないため、Office がサーバー側で実行されている場合、一般的な Office の安定性は保証されません。 ネットワーク サーバーで Office をサービス コンポーネントとして使用すると、そのコンピューターの安定性が低下し、ネットワーク全体の安定性が低下する可能性があります。

GPTとの会話をのせておきます

自分：動的にインストールする話がかかれてますが、そういったことをしないのであれば、この話は関係ないということでしょうか？

GPT：はい、その認識は基本的に正しいです。

この部分に書かれている「回復性と安定性」に関する注意は、特に以下のような**“動的な機能インストール”や“自己修復”が発動するような場面”**に対しての警告です：

該当する「危険なシナリオ」 Officeには以下のようなMSIベースの仕組みがあります：

初回使用時にインストールされる機能（Install on first use）

特定の機能（たとえば数式エディター、図表描画ツールなど）は、Officeの最初のインストール時にはインストールされず、使おうとしたときに動的にインストールされる設定になっていることがあります。

自己修復機能（self-repair）

Officeの構成に何か欠損があると、起動時に自動的に再構成や修復が走ることがあります。

ユーザー単位で異なる構成が適用されることがある

特にマルチユーザー環境で、ユーザーごとにOfficeの状態が異なる場合があります。

🚨 サーバー側でこれが発動すると何が起きるか？ インストールメディアの要求（＝ダイアログボックスが表示されてハング）

インタラクティブな操作ができず失敗

サーバーの安定性が下がる（特にIISやバッチジョブ実行中にOfficeが待ち状態になる）

✅ バッチ処理のような用途で問題が出るか？ → 原則として「いいえ」、問題にならないケースが多いです。 なぜなら：

バッチ処理で使用するOffice機能を事前にすべてフルインストールしておけば、「初回使用時インストール」や「自己修復」は原則発動しません。

事前に実行アカウントでOfficeを起動し、必要な機能が問題なく動作することを確認しておけば、突発的なインストールや修復の可能性はかなり低くなります。

さらに、Office 2016以降（特にC2R版）では、このMSIの挙動はかなり簡素化・抑制されています。

最後

サーバーサイドのセキュリティ: Office アプリケーションは、サーバーサイドで使用するように設計されていません。 そのため、Office アプリケーションは、配布されたコンポーネントで発生するセキュリティの問題を考慮していません。 Office は受信要求を認証しません。 また、サーバーサイド コードから、予期しないマクロの実行や、マクロを実行する可能性がある他のサーバーの起動を阻止する機能もありません。 匿名 Web サイトからサーバーにアップロードされたファイルを開かないでください。 サーバーは、最後に設定されたセキュリティ設定に基づいて、完全な特権を持つ管理者またはシステム コンテキストでマクロを実行できるため、ネットワークが侵害される可能性があります。 また、Office は処理を高速にするために、クライアントの認証情報をキャッシュできる多くのクライアント側コンポーネント (Simple MAPI、WinInet、MSDAIPP など) を使用しています。 Office がサーバーサイドで自動化されている場合、1 つのインスタンスで複数のクライアントにサービスを提供する可能性があります。 そのセッションで認証情報がキャッシュされると、あるクライアントが別のクライアントのキャッシュ済み資格情報を使用する可能性があります。 結果として、そのクライアントは他のユーザーになりすまして許可されていないアクセス許可を得る可能性があります。

この話では、素性のわからないファイルを実行してはいけないという話なので、プログラム自身が生成するような用途だとこの問題は該当しないと考えています

いろんなリスクはあるものの状況によっては回避し問題が起きる可能性は下げれるものの、ただサポート外の動作であるため、やはり使わないことがベストという話になります

続いてライセンスの話

技術的な問題とは別に、ライセンスの問題も考慮する必要があります。 現在のライセンス ガイドラインでは、クライアントにライセンス認証済みの Office がインストールされている場合を除き、クライアント要求を処理するサーバー上で Office アプリケーションを使用することは禁じられています。 サーバーサイド オートメーションを使用して、ライセンス認証されていないワークステーションに Office 機能を提供することは、ソフトウェア ライセンス条項 (EULA) では認められていません。

サーバー側にライセンス無しでの実行がNGなのは言うまでもなくだと思います・・

最終的に・・・

Microsoft では、サーバー側ソリューションを開発する必要がある場合は、開発者が Office の Automation の代替手段を見つけることを強くお勧めします。

別手段で実行することを推奨しています。そのため、何かしらのライブラリを使用しての対応が必要になってくるという話ですね・・・

なので、COM経由の操作は許可しているものの、ユーザーがログインしている状況化で、アプリを表示した状態で実行し意図しない動きの場合に対応ができることが前提という話になるので、サーバーでは技術的につかわないようにという話でした・・・