経験上、以下の二点があります。
・サーバ設置場所移動
・ビルメンテナンスによる全館停電
※クラウド・データセンターで運用している場合は無縁ですね。
注意点としては複数のサーバ、たとえばWebサーバ、アプリケーションサーバ、DBサーバと筐体を分けて構成している場合、どれかひとつをシャットダウンしたいのであれば、一時的にサービス自体にアクセスできなくする運用が望ましいかと思います。あと、Zabbixのような統合監視サービスを導入しているのであればシャットダウン期間中は一時的に監視対象からはずすなどしないと警告メールがたくさん飛んできます（笑）

近々、サーバー入れ換えで土日にやる予定がありますが、土日に仕事があるシフトの人達には、勤怠管理の個別対応をユーザーと人事にお願いする予定です。

電源の点検も近日中に行います。

あと、個別のアプリケーションメンテナンスも近日中。

なんか、あれこれ多いなぁ、、。(^;

　・障害対応やファームウェアのアップデートなどメンテナンスによりシャットダウンor再起動が発生

　・サーバにより動いているサービスが異なるのため、シャットダウンの手順を確立させておく必要がある。
　　（サーバのサポートに手順をレビューしてもらったほうが良い）

　・シャットダウンするサーバに関係するサーバやネットワーク機器の影響範囲の確認と対応手順の作成

　・サポート業者や利用ユーザーへの通知

　・再起動する前提があるのであれば、起動後の疎通やサービスが動いているかの確認手順も必要

　・クラウドサーバでも、AWSなど従量課金制のサービスであればサービス提供時間外はシャットダウンさせることも検討しましょう。

　・あと、Windows の497日問題 なんてものも。。。
　

停電のような物理的な理由、ソフトウェアのアップデートによるメンテナンスなどを除けば、安定稼働のためでしょうか。

最近はWindowsでも24時間365日稼働となっていますが、実際には長期間の連続稼働で発生する障害もあるし、可能であれば日々、あるいは週に一回でも再起動しておくと安心できます。

まぁ、ここ最近のOSは安定してきたし、ちょっとした設定変更で再起動を求められることもなくなってきたので、最初に書いた理由以外では無理に止めなくても良いとは思います。なので、この辺りは趣味の問題だと思います。

ちなみに、私の勤め先の運用ポリシーは、毎日、あるいは休日の早朝に再起動（もちろんスケジューラーで自動実行）です。

もっとも、メールサーバーみたいに業務上止められないシステムは止めません。

また、あるサーバーが動作していることを前提に動いているシステムがあった場合、シャットダウンの順番とか、事前にサービスを停止しないといけないとか、そういう手順の確認は必要だと思います。

今まで経験があるのは、
・フルバックアップ取得時
・ビル全館停電
あと、初めてUPSのバッテリ交換したときは「念のため」と言い張ってサーバーを
停めたことがあります。
再起動しなくなる事が怖いので、サーバーが古くなればなるほど停めない傾向に
あります（ｗ

注意点はみなさん書かれているとおりですが、１つだけ追加です。
「起動中のサービスはすべてスタートアップに入っている訳ではない」
停める前に今動いてるサービスをすべて控えておかれた方が良いかと
思います。（ウチに限った事かもしれませんが）

皆様、ご回答ありがとうございます。いろいろなことを知ることができて、少しだけ理解が深まったような気がします。