UMLを設計に使うつもりでいますか？
それだと、設計変更や製作の「速度」に対して、作図する手間がかかりすぎるのかなと考えています。

弊社現場でも、フラグが複雑になってきたら、ステート図で状態を整理したり、分岐や処理順が思ったとおりでないときなどに、部分的にアクティビティ図、シーケンス図を描いて「この手順を正としましょう」という意思統一をすることはあるのですが、案件全体でその粒度の図を書くことはほぼありません。

作図粒度の問題もありますが、何から何まで描いていると、Slack、口頭指示レベルで"もの"の方が上がってきてしまうので、描いてる間に"指示書"としては不要になってしまうんです。

ただ、引き継ぎ案件などで感じるのは、「全体フロー、せめて顧客の要望で作り込んだ機能だけでも、仕様書として欲しいよな‥」です。

次の改修担当（自分かもしれないけれど）に引き継ぐ書類としての意識であれば、先に挙げたような視点で「次の人が困るだろう」という点に限って作図し、どうでもいい部分の作図に手間をかける必要はなくなります。
それでも、時間が経って、メンテナーが当時の開発担当ではなくなった際に役に立つでしょう。

UMLをどういった粒度で利用したいのかは組織によると思いますが、

"設計書"(開発前・中)としては意識合わせのために局所的利用（おそらく現状できているのでしょう）は変える必要はなく、

ある程度案件が仕上がってから、意識合わせが必要だった場所の前後も必要に応じて補完し「仕様書を残そう」（または仕様書の規格に加えよう）という方針を提案してみたらいかがでしょうか？

@yazioh

UMLを設計に使うつもりでいますか？

完全に見落としていました、まず前提が違いましたね。

UMLは、本来は設計書として使えるものとして登場していますが、質問文ではUMLを設計書として考えている書き方をしていませんでした。
どちらかというと、俯瞰図や引継ぎ資料など、「今のアーキテクチャを見やすくする」ツールとして書いていました。
こちらは、質問文を修正します。

設計変更や製作の「速度」に対して、作図する手間がかかりすぎる

設計書としての公式な文書としては、確かに変更速度に追いつかない、というのはその通りだと思います。

ただ、設計書としては私も書きませんが、自身の頭の整理のために書くことはあります。
全体的な使用例くらいは、シーケンス図やユースケース図で書いて、大雑把な想定を洗い出しますし、ざっくりとしたアーキテクチャを配置図で書いたりします。
もしかしたら、皆さんも同様なメモを書くことはあるかもしれませんが、その記法としてUMLを選択しないだけかもしれませんね。

引き継ぎ案件などで感じるのは、「全体フロー、せめて顧客の要望で作り込んだ機能だけでも、仕様書として欲しいよな‥」です

まさにその通りです！

だからこそ、最初から作っておけばよかった、と思うのですが、上記の「変更速度に追いつかない」問題によって、最初は作らないんですよね......
変更速度に追いつけるようなシステムが開発されれば、もしかしたらUMLも復活するような気がしてきました。

ありがとうございます。