文字種に対してある種の強制を入れるのは伝統的なセキュリティ施策で、WindowsでもActive Directoryの設定により「大文字、小文字、数字、記号のうち3種類以上を使用する」等は一般的なポリシーです。ウェブサイトでもこの種の制約はよく見かけるところです。
これに対して、私は徳丸本初版（2011年3月）にて、以下のように書いていまして、文字種の強制がセキュリティ強化につながらない可能性を暗に匂わせつつ、それは明示しないという慎重な態度を取っていました。
その上で、以下に続きます。文字種の強制への批判を匂わせつつも、「伝統的な対策」に寄せた記述になっています。私は徳丸本初版の執筆時には、自著がここまで「標準的な教科書」になるとは想定していませんでしたが、企業の研修などで使われることは想定して、あまり過激な持論を展開することは避けようという意図がありました。
この種のポリシーチェック（文字種の強制など）は、やり過ぎるとかえって「パスワード決定は利用者の責任」という原則を忘れさせるという心配はありますが、危険なパスワードを減らす上では一定の効果があると考えられます。
先の「Password1!」の箇所は徳丸本2版（2018年6月）でも残っていますが、NIST SP 800-63B（2017年6月）に以下の文章が入ったことから、一気に強気になりますw
Verifierは他の構成ルール(例えば，異なる文字種の組み合わせ，一定の文字の繰り返し)を記憶シークレットに課すべきではない(SHOULD NOT)．Verifierは，記憶シークレットを任意で(例えば，定期的に)変更するよう要求すべきではない(SHOULD NOT)．]
https://openid-foundation-japan.github.io/800-63-3-final/sp800-63b.ja.html より引用
openid-foundation-japan.github.io
これを受けて、徳丸本2版では、先程の引用箇所は以下のように変化しました。
文字種の強制は過去には弱いパスワードを避けるコントロールとして考えられていて、NIST SP 800-63Bではそれが否定されたわけですが、代わりに同書では以下が推奨されています。
記憶シークレットの設定，変更の要求を処理する際，Verifierは候補となっているシークレットの値を，一般的に利用されている値，予想されうる値，危殆化した値として知られている値を含むリストに対し，比較するものとする(SHALL)．例えば，以下のリストが含んでいるものでよい(MAY)が，限定するものではない:
・過去に漏洩した語彙集から得られるパスワード
・辞書に含まれる言葉
・繰り返しまたはシーケンシャルな文字 (例： ‘aaaaaa’，’1234abcd’)
・サービス名や，ユーザ名，そこから派生するようなものなど，文脈で特定可能な単語
https://openid-foundation-japan.github.io/800-63-3-final/sp800-63b.ja.html より引用
確かにこの方が効果的だと思うものの、これの実装はなかなか厄介です。これを実装しましたという記事もあまりテックブログ等でも見かけないのですが、例外としてpixivの事例があります。
https://inside.pixiv.blog/2020/01/22/180000
この記事でも、NIST SP 800-63Bは参照されていて、かつ以下のように、pixivの施策はこれに影響を受けたものと明記されています。
漏洩パスワードを設定できなくする本施策はこの見解（引用注: NIST SP 800-63B）に沿うものです。なお、「辞書にある単語」や「繰り返したり順番になっている単語」もその多くが漏洩パスワードに含まれているため、別途追加することはしていません。
長々と展開しましたが、モダンなパスワードポリシーはpixivの施策ではあるものの、実装が大変であるため、簡便法として「伝統的な文字種の強制」が採用されていると私は位置づけています…が、単に不勉強で、伝統的な方法を採用している可能性も高いですw