自分も何度も悩んでます。昔は「バリデーションはAPIの入口でやるのが正解」くらいに考えてたんですが、プロジェクト進めてると、そこまで単純じゃないなって気づかされます。

最近のプロジェクトで、バックエンド側でしっかり型定義してたのに、フロントの状態管理層で同じバリデーション書くことになって、二重化してて保守が面倒になった経験があります。結局、どちらかが更新されると整合性が取れなくなる感じで。それ以来、「型システムでできることと、ビジネスロジック的なバリデーションは別」って区別するようにしてます。

TypeScriptだと型チェックは開発時にある程度補完してくれるので、その段階で「nullableな値」とか「想定外の値」は早期に気づける。ただし、外部APIからのレスポンスやユーザー入力みたいなバウンダリーレイヤーは、実行時のバリデーションが必須な気がしています。

今は、層ごとに役割を分ける方針で落ち着いてます。型で表現できるスキーマ的な制約はそっちに、ビジネス的な「この値は年齢として妥当か」みたいなロジックは、実際のバリデーション層に。完全には分離できないケースもありますが、その度に「ここでやる理由は何か」を考えるようにしてる。その思考プロセスが次の設計につながってる気がします。