А зачем он?

для удобства. Ну варианты http/websocket-ы. Почему бы не gRPC еще.  Формальная спецификация протокола удобней

Ну, вообще он скорее неудобен. Жесткие ограничения на сервер, отсутствие нормальных библиотек на клиенте, необходимость кодогенерации, сложность изменений протокола. При этом никакого выигрыша по сравнению с банальным json по OpenApi не будет.

grpc гораздо более сложный протокол. + нужно будет держать либо две схемы, либо платформозависмые костыли.
третья версия чисто про транспортный формат, где нет даже признака обязательности поля. а валидация на уровне прото файлов выполняем платформозависимиыми плагинами для генератора, т.е. такие дефиниции уже неперносимы между двумя различным экосистемами, например из жвм в го или жс. либо поверх описывать уже схему пригодную для строгой валидации каким либо образом

для меня кодогенерация всегда плюс. Чем меньше руками пишется, тем меньше ошибки.  Валидацию можно сгенерить для target языка самому исходя из специфики задачи.

Ну если обмениваться json то тут и вовсе же не надо ничего по сути генерировать/писать. Разве что вызовы методов сериализации/десериализции объектов

Не, меньше - не пишется, скорее наоборот. Но при этом сборка становится сложнее, разработка тоже, многие возможности IDE пропадают. Да и в кодогенераторах полно ошибок, которые исправлять гораздо дороже.

в grpc хотя бы oneof работает :)

Вообще, я почти никогда не видел использования gRPC по делу. Всегда хайп...

Так в OpenApi он тоже есть. Вопрос - во что он при этом превращается при кодогенерации в разных языках (иногда в дикую кривизну)

И кто из кодогенераторов его умеет? :)

в генеренный код обычно руками не лезут, либо подход такой, что код правится внутри методов или явных секций
видимо у всех свой опыт.  Зависит кто откуда пришел  :)
мне спецификацию на protobuf быстрей глазом охватить чем openAPI доку

Пытаются - многие )

Тот же allof вроде как тоже в спеке есть, но всеми любимый swagger ui его не умеет отображать корректно.

А, я вообще пишу спецификацию на котлине, а по ней уже делаю OpenApi для тех клиентов, кому надо.
Это получается удобнее всего (так как ide для спецификаций в OpenApi удобных нет)

я за последние пару лет yа Go перешел с Java

Соболезную

да не, мне нравится

Java тоже осталась в активе

сообственно, могу сразу на всем писать. Включая С++ и Python еще. Просто Go как бы основа