Ну на самом деле мы этим и занимаемся на бэке, просто затягивая технологии для повышения своего JSI (шутка, с долей правды).

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

Обязательность полей: застолбив контракт как not null, то вы гарантировано получите из бэка консистентные данные, да, есть конечно в open spec required - но это больше соглашение, чем обязанность, в gql бэк сам обделается и ответит ошибкой.
Строгая типизация: тут немного с другой стороны попробую показать. Вот у нас есть условно банковские счета и метод, который их возвращает. Как нам в rest (при использовании json) подчекрнуть тип? Я пока знаю только 2 способа, но оба упираются в поле. Давайте по-простому сделаем?
{
"type": "DEBI",
"title": "any",
"number": "1111",
"balance": 1000.00
}
{
"type": "CREDIT",
"title": "any",
"number": "1111",
"balance": 1000.00,
"availableCredit": 10000.00
}
Тут у нас только соглашение, что у json в котором поле type имеет значение CREDIT должен быть availableCredit, но не у json с type DEBIT.
Как выглядит в gql?
interface Account {
title: String!
number: Int!
balance: Float!
}
type DebitAccount implements Account {
title: String!
number: Int!
balance: Float!
}
type CreditAccount implements Account {
title: String!
number: Int!
balance: Float!
availableCredit: Float!
}
Может быть неочевидным, но второй вариант и может быть расширен еще другими типами и будет нести гарантии в контракте, что удобно и клиентам и бэку.
Ошибки и graceful degradation: допустим бэк написал BFF на ресте и джоинит сам dto от других сервисов (конечно это такой себе вариант и лучше бы тогда CQRS использовать, НО реальность такова, что это достаточно дешевый и быстрый подход), как можно сообщить клиенту, что какую-то часть данных он не получит? Можно допустим кинуть ошибку и отдать, то что есть, можно ничего не отдавать, можно не отдавать данные, которые достать не получилось. В общем, доводить клиентов до истерии.
Как решено в gql? те данные, при выборке которых произошел фейл - отдается ошибка, оставшиеся приходят клиенту, т.е. клиент осведомлен о том, что чего-то не хватает и принимает решение, как с этим работать, т.е. может отобразить ту часть данных, которую можно -> graceful degradation возможен без приседаний (пользуются ли этим? не всегда, клиенты привыкли получать 4хх или 5хх)