世の中には俗に言う「塩漬けシステム」というものが存在します。明確な定義は無いのでしょうが、EoLはとうに過ぎているのに、改修が難しかったり、システムをなかなか止められなかったり、コストがかかるからやりたくなかったりで、「とりあえず動くからそのまま放置されている」システムといって大抵のIT関係者にはイメージの違う部分は無いのではないでしょうか。
IT業界に携わったことのある者なら多かれ少なかれ誰でもそういった現場を見ていると思います。個人的には表に出てこないだけで、そうしたシステムは至るところにあるのではないかと想像しています。
さて、AWS LambdaやGoogle の Cloud Functions等のサーバーレスのリソースを運用していると、数年に一度、ランタイムのEoLに伴い、関数のランタイムの移行をしていると思います。
例えば、私は普段AWS Lambda(Ruby)のメンテナンスをしていますが、先日受け持っている Ruby 2.7 の関数をすべて 3.2 に移行しました。AWS LambdaのRuby 2.7ランタイムは2023年12月7日にセキュリティパッチ当てや新規作成ができなくなり、その後、コードの更新もできなくなります（Lambda ランタイム）。
また、GoogleのCloud Functionsでは、非推奨期間を経て廃止に至ると、そのランタイムは無効ないし削除される可能性があるようです。
廃止日以降は、そのランタイムを使用する新しい関数の作成と既存の関数の更新ができなくなります。関数をデプロイするには、最新のランタイムを選択する必要があります。廃止されたランタイムを使用し続ける関数は、無効にされる可能性があります。
ランタイム サポート | Google Cloud Functions に関するドキュメント
https://cloud.google.com/functions/docs/runtime-support?hl=ja
と、このようにサーバーレスを使っていると実行環境がクラウドプロバイダー側になるということもあり、EoLに至ったランタイムをどうにかこうにしかして使い続けるということは非常に難しくなります。ここまでのリスクにさらされれば、システムを塩漬けのままにしておこうという判断はされにくいでしょう。
サーバーレスのメリットとして、スケーラビリティやメンテナンス性等はもちろんですが、ほぼ強制的にシステムの更新を余儀なくされる（＝技術が経営サイドを説得しやすい）という点もあるのではないかと思います。