銀の弾丸ではないので良し悪しあるのは当然として、それを差し引いても以下の2つの要素があるのではと思った。
なんとなく使ってもメリットが十分得られない
RESTでできてたことができなくなる（※ちゃんと調べればできる）
なんとなく使ってもメリットが十分得られない
Web界隈は良くも悪くも新しい技術をとりあえず使ってみるところがあると思っていて、そこがGraphQLは十分に事前知識を持って導入しないとメリットが薄いところとミスマッチを起こしてネガティブな意見が出るのかなと思う。
GraphQLはもともとFacebookがReact, Relayとの組み合わせで使い始めたもので、クライアントライブラリとしてのRelayと、IDやページネーションについての追加仕様を公開している。ライブラリとしてのRelayは使わなくても仕様に乗っかることはできるのでそれをRelayスタイルと言ったりする。出典を忘れたが「RelayスタイルじゃないGraphQLに価値はない」とか言ってるGraphQL有識者もいて、過激な意見とは思うが結構その面はあると思う。Relayスタイルを知っていて採用しないことはあっても、知らないままでGraphQLを使っていくのはまずい気がする。
そうは言ってもRelayがOSSになった当初はかなり独特なAPIで、FlowだけでTypeScript非対応だったりと非Facebookの人からするとApolloのAPIのほうが馴染みやすかったと思う。今ではRelayもかなり改善されているがそういった事情もあって、Relayを使わずにRelayスタイルが広まるということもなくRelayスタイル抜きにGraphQLが普及していったところがある。
Relayスタイルを抜きにしてもFragment Colocationってなに？ってレベルで使うと良さはほとんど出ないと思う。じゃあどうすれば十分な知識得られるんだというとその辺がしっかりまとまってないのもGraphQLの良くなさとは思うが、定番としてはProdution Ready GraphQLとか、前述のRelay Specに乗っかっておけばだいたいは良いと思う。Relayの人がGraphQL成熟度モデルというのをXでポストしていてそれも参考になるかも。Relayチームの人やGraphQLライブラリを作っている人とかは日々Xで不当なGraphQL批判と闘っている（？）ところはあるのでフォローすると有益な情報が得られるかも。
RESTでできてたことができなくなる（※ちゃんと調べればできる）
GraphQLへの批判として良く言われる、DBと密結合でけしからんとかN+1が起きるとかレスポンスが10MBになったのでクソとかログがまともにできないとか…そのへんの意見は率直に言うと調査が足りないのではと思うものの、Web界隈特有のなんとなくで使い始めるとRESTとの差異からこういった問題が続々と出てきてしまうのだろうと思う。RESTで当然できていたことがGraphQLを使うとできなくなったのだから批判的になるのもわかる気もする。RESTなメンタリティで使っても良いところは出ないと思っていてその意味ではアンラーニングを要求するのかもしれない。
ついでに最近のGraphQL界隈の火元とかその後出た記事とかを貼っておく。
ある日SentryのCTOの人がこういうポストをして俺もそう思うぜ！とかGraphQL関係者から反論が来て議論になったりと論争が巻き起こった。
要するにGraphQLはフロントエンド最新技術でみんな使え！ってわけじゃなく、マッチするケースなら使えばいいじゃんという単なる退屈な技術だよと言っていてそういうことかもと思った。
追記
tRPCの方が良い
というコメントを某所で頂いたが、単一のクライアント・サーバーで両方TypeScriptにして最速で開発する的なケースであればそうだと思う。GraphQLのスイートスポットはそことは違うとGirouxニキは言っている。