Может тогда и разделение на фронт/бэк не нужно, давайте снова рендерить на сервере статичные странички

Ну а чем это в сущности отличается от написания actions или вызова хитрых методов?

Уровнем абстракции

Экшн - это просто "некое событие", а сетевой запрос это обособленный узкоспециализированный уровень

Это не вопрос, мы так и делаем, стираем границы между беком/фронтом. Мы просто говорим, что есть данные которые нужны, чтобы отобразить именно эту страничку именно с этим состоянием. Все. Откуда там прийдут данные (кеш, сервер, локальные резолверы) абсолютно неважно именно для компонента/страницы. У него есть язык работы со всеми этими данными и для него они просто становятся едины.

Тут как раз я вижу абстракцию в работе с данными, а отличие от

Почему на сервере нет redux/flux/... ?

Сам по себе graphql придуман для задач, не связанных с поведением ui. Пришли клиентописцы и сказали "а давайте применим инструмент клиент-серверного взаимодействия для операций внутри клиента". Wtf?

Как это нет?
Во-первых, библиотеки для стейт-менеджмента вполне себе существуют и применяются (лично видела код на рельсах с применением одной из них, в clojure это ещё популярнее)
Во-вторых, это не всегда нужно, потому что у нас УЖЕ есть транзакционная модель в СУБД, это ли не стейт-менеджмент?

А еще пришли ребята и сказали, давайте из всего сделаем graphql (бам!) и сделали – и это оказалось удобно. Как универсальный язык запросов к данным, который покрывает нужды большинства приложений. Да, не все, но достаточно. Такая себе абстракция над маперами, которые мы раз за разом пишем для работы с данными в приложении.

Тогда почему стейт-менеджеры не могут с СУБД хотя бы элементарную?

Хотя как написано выше, у них же одни и теже задачи на беке

А зачем использовать их для работы с субд, если в самой субд и так есть такой же слой абстракции? Просто субд - только для данных, всем остальным пусть занимается отдельный слой

А зачем прикручивать нормализацию в redux костылем сбоку? Зачем писать кучу редьюсеров ни о чем? Зачем делать хитрые селекторы по данным? Делать стор персистентным? Что-то там для сайд-эффектов добавлять сбоку?
Посмотреть на любое большое приложение со стором – в нем уже будут реализиваны кучу функций из СУБД, но криво-косо-несовместимо-размазанно и прочее. Ну так зачем тащить эту храмую лошадь раз за разом в новые проекты?
Ну и мы приходим к тому, что у нас есть Apollo только для данный (Query/Mutation/Fragment), с полным контролем над ними в отдельном слое. И связь этих данных через компоненты, которые эти данные и отображают, зная полную модель их.

Мы пишем мапперы, потому что люди придумали отделять данные от представления в целях предсказуемости поведения, прозрачности отладки и гибкости проектирования. Зачем эту логику обратно прятать и как теперь её отлаживать, копаться в исходниках gql-клиента?

А зачем думать об этом? Ну если за это платят, то ок, но мне лениво делать это раз за разом. Пусть этим занимается отдельный клиент, который и так под это заточен и делает это с данными с бека.

Кроме редакса есть и другие стейт-менеджеры, в которых многие ошибки редакса учтены и имеется более минималистичное и консистентное апи

Окей, можно смотреть на Apollo как на еще один такой стейт-менеджер. Кто захочет попробует, если оценнит – круто, если нет, то redux/mobx/... никто не запрещает.  Можно просто не подключать кеш в Apollo и использовать его чисто как api для запросов и после все хранить в сторе.

Но говорить про костыльность этого решения, на фоне полного набора костылей в других менеджерах по меньшей мере недальновидно

ткни носом про что ты говорить, нагуглил только строчку в конфиге