React.FCをやめる必要はない

React や TypeScript に限らず、明示的に型をつけた方が良いという主張です。
帰結として React.FC をやめる必要はないと思います。

なぜ明示的に型を付けた方が良いのか

理由 1: コードが少しだけ分かりづらくなる

型推論をコンパイラに任せたコードは書くのが楽で見た目もスッキリします。
一方で読み手の人間の負担は少しだけ増えます。
ソースコードに書かれていない情報を読み取る必要が出るからです。

最近のエディタ / IDE はマウスホバーで型情報を表示してくれますね。
しかし例えば GitHub 上で PR を見ているときは違います。
型を確認するにはコードの別の箇所を見るか、ローカルでチェックアウトすることになります。
またエディタ / IDE で見る時も明示的に型が書かれていればそもそもホバーする必要はないです。
これらの読み手の負担は微々たるものですが、読まれる度に発生します。
一番の理解者である書き手がさっさと型を書いてしまうのが手っ取り早いですね。
個人的にはそうするのがプロとしての丁寧な仕事だと思っています。

余談ですが Go がエラーを明示的に返すのも同じ理由だと思っています。
Java のような例外機構では非検査例外が投げられるかがほとんど分からないです。

理由 2: 予期しない型が付く、予期しない型の変更が起きる

型付けの甘いライブラリを使っていると予期せぬところで any が混入することがあります。
また一見型が付いているように見えても型パラメータのデフォルトが any の場合は同様です。
ライブラリの型が使えるなら使うのが一番楽ですが、まっとうな型であるか確認しましょう。
まっとうでない場合は制約を強めた型を自分達で定義しましょう。
ライブラリのリポジトリに Issue を立てるなどしてフィードバックすると尚良いと思います。

また実装当初は意図通りの型が付いていたとしてもその後の修正で変わることがあります。
その際明示的に型が付いていれば型エラーによって型の変更を知ることができます。

React の場合

React の場合はコンポーネントに React.FC のような型をつけたり、Custom Hooks の返り値の型を明示したり、ということになります。

わざと React.FC を使わない場合

Generics を使いたい場合が挙げられます。
また ReactElement 以外の要素を返す特殊なコンポーネントも当てはまると思います。
プロジェクトで React.FC を書くのがデフォルトになっている場合は、型定義が React.FC でない時点でこれは特殊なコンポーネントなんだなと認識してからコードを読むことができます。
もちろんこれらの場合も返り値の型を明示するのが良いと思います。

最後に

自分で言うのもなんですが割と細かい話ですよね。
実際自分がレビューする時は変数宣言の型や返り値の型が明示されていなくても特にコメントしていません。
自分が書き手の時だけ意識していますが、全エンジニアが意識したら少しだけ優しい世界になるのではないかと思っています。