>Денормализованная выдача не совсем, справедливо только для json-сериализации. любой другой сериализатор

с возможностью внутренних ссылок позволяет исключить дубликаты.

>GQL - это просто RPC.
при помощи graphql можно построить RPC, но сам он таковым не является.

>Нестандартизированные параметры
да, но я не сказал бы, что это минус. Универсальным инструментом для работы с разными апи является клиент graphql - благодаря тому, что схемы экспортируются. Изобретение одного универсального API не лежит в сфере задач graphql.

>Все запросы POST-ом, все ответы с кодом 200. Соответственно браузер никак не помогает всё это дебажить.
а что именно вы дебажите? ответы резолверов? реализацию собственного graphql? я не сведущ в разработке под веб, но я не вижу проблемы испольвать дебаггер IDE для отладки браузерного кода, благо для chrome и для node он один и тот же.

>HTTP кеширование не работает
потому что graphql никак не связан с HTTP

>Все эти типы, фрагменты, мутации и пр на собственном ограниченном языке, требующем писать много кода для простых вещей. Без библиотек и спец-инструментов использовать очень сложно.
этот собственный язык очень ложится на описание систем, которые следуют DDD/CQRS. Простые вещи описываются простым языком, все сводится к командам (мутациям) и проекциям (queries).

>Нет загрузки файлов
да просто Buffer кидаете в команду и все. зачем base64? если вы сериализуете через json, then don't. Если вы привязаны к JSON, вижу несколько вариантов:
1. кодировать в json и менять буфферы на какой-нибудь { __type: "Buffer", content: "base64..." },
2. или же отправлять через multipart form data, заменяя буфферы на ссылку на content disposition.

в самом graphql нет "файлов", потому что файлы ничем не отличаются от остальных данных. вы хотите транспорт бинарных данных, и он в graphql есть, очевидно.

>Легко простым запросом выгрузить на клиент всю базу, что положит сервер.
почему же? с каждым запросом у вас есть объект контекста. каждый из узлов запроса может менять и смотреть этот контекст. если ваши запросы превышают какую-нибудь эвристику предела вложенности, вы можете отказаться дальше рекурсивно спускаться и вернуть какую-нибудь заглушку типа "превышена глубина запросов", или отменить ответ в принципе. Более того, вас никто не заставляет подготавливать все данные сразу же, вы можете сначала оценить потенциальный размер ответа и потом принять решение, хотите ли вы его отправлять и на самом деле извлекать из бд, или ну его нафиг.

Можно много фантазировать про не json сериализацию, но её поддержки нигде нет и не планируется. А используя что-то своё, вы теряете все преимущества перед любым самопальным протоколом. Он по факту имеет семантику РПЦ указанные следствия из этой семантики. Думаю вам стоит поработать в вебе немного, чтобы понимать что и как там дебажится. Через ide подключиться не всегда возможно, не всегда удобно, и опять же нужна спец поддержка этого протокола, которой нет и не предвидится. В том и проблема, что он никак с хттп кешированием не связан и ломает его полностью, вместо того, чтобы использовать его возможности. Всё сводится к копипасте, очень много копипасты. Прочитать объект - один код, положить его обратно - другой код. Оценить ресурсоёмкость запроса - задача не из простых. Сформировать конечное число запросов к бд по произвольному запросу к серверу - ещё более сложная задача.