◆ 分けるメリットないし 1 つに揃えたほうが実装が楽
  ◆ URLSearchParams や Request Body で別にパースいらない
  ◆ わざわざメソッドを指定しなくていい
  ◆ 追加削除などなにするかわかりやすいというのは URL のパスで十分
◆ 特に内部的に使ってて仕様公開しない API とかは全部 POST で困らないと思う

使い分ける必要性ない

ユーザが直接アクセスしないような 内部的に使ってる application/json を返すページ
REST API 的にはすることに応じて GET/POST/PUT/DELETE とか使い分けるべきなんでしょうけど
そうしないといけないわけでもなければ そうするメリットもたいしてないです

GET だと URL になるから BOT にアクセスされて困るものは POST にするとか
URL の文字数限界になるような多くのパラメータがあれば POST にするとか
単純に開くだけで同じものが見れるよう共有用 URL であれば GET にするとか

使い分ける理由がないわけではないですが 最初に書いたような内部的に使ってるものだと 全部 POST でいいと思いました
POST なのは基本は GET/POST の 2 つしか使われないことがほとんどで GET の場合は上で書いた文字列の長さの限界があるからです
バイナリを base64 送ったり 長さ的に困ることがないならアクセスログが残る GET でもいいかもしれません
リクエストの HTTP Header でトークン送るのを必須にすれば GET で追加や削除できても URL をブラウザで開いただけでデータ消えるなんてのもないですし

分けないメリット

全部同じにする理由は単純に全部同じに揃ってるほうが実装が楽だからです
GET と POST だとデータの送受信方法が違います
URL をビルドしたり POST するフォーマットにしたり Content-Type を指定したり リクエストメソッドを指定したり
サーバ側ではそれぞれを別にパースしないとですし追加の作業が増えます
全部が POST それも Content-Type は JSON 固定にすれば JSON の送信とパースのみの対応でいいので面倒な部分がかなり減ります

フレームワークによっては全部自動でやってくれてリクエストメソッドの違いなんて気にしなくていいものもあるでしょう
やっても大した手間にならなくてやりたいならすれば良いと思いますが やらないといけない理由は特にないと思うのですよね

一応初めて見る人なら GET とか DELETE とかメソッドの種類でなにするかわかりやすいメリットはあると思います
しかし 今回は前提として内部的なもので他の人に見せて使ってもらうこともなければどっちかと言えば知らない人には分かりづらい方が良いくらいです
それに POST データに応じて追加や削除が切り替わるのは作る側的に複雑になることも多いですし URL で追加・更新・削除・取得などを示してることがほとんどです

ユーザを操作する例だとこういうの

/user/insert
/user/update
/user/delete
/user/select

なんとなくで RDB の命令風な名前にしてみました
文字数揃って綺麗ですし

これを /user をパスにしてメソッドを POST, PUT, DELETE, GET にしたものが理想なものでしょう
メソッド変えるだけで済むならいいですが それだけのためにデータの受け渡しも変えるのは面倒すぎです
特に GET/POST の違い
それに別のメソッドというものより URL のパスだけ見てわかったほうが楽で便利ってことも多いのですよね

たとえば fetch 関数なんか URL 指定だけならともかく メソッド指定なら第二引数のオブジェクトで method を指定となってるわけですし

主に GET/POST 間

全部まとめるとは言ったものの PUT や DELETE なども含めてしっかり使い分けてるのはそこまで無いと思います
HTTP Method をちゃんと使ってますよーというの売りにしてるところくらいで それ以外のほとんどでは GET/POST の 2 種類だけでしょう
なので抵抗あるとすれば GET と POST をまとめるというところくらいだと思います

普通のページが全部 POST は流石に嫌ですが 内部的に ajax でサーバから情報取得する部分が GET じゃなくて POST になって困ることなんてまずないですし そんなに迷わず全 POST でいいやと思えました