Имхо, функция ветки develop в том, чтобы другие разработчики, а может и даже сам могли получить последние изменения в других задачах не дожидаясь релиза

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

Когда релизы 1-2 раза в день, то ветка develop как правило совпадает с веткой релиза, в чём её польза тут?

а кто все? если често - я только разговоры слышу.
и единственная компания что шла по честному git flow - контора выпускающая коробочный системный софт

это из тех что знаю.

работа с ВКС вообще одна сплошная боль))) с теплотой вспоминает свои пет-проекты из 2008го, когда по фтп файлики на прод скидывал и будь что будет

В целом вы конечно правы. Но бывают различные ситуации. Например код не обратно совместим с фронотом, а изменения на фронте еще не реализованы т.к. зависят от бэка. И фронту нужно обращаться к какой-то кодовой базе(например develop). Да, конечно это можно организовать без develop-а, но это уже вопрос инфраструктурный

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

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

Извините, если показался токсичным, в большинстве случаев задача не на порядок сложнее, а просто после выклдки нужно подчистить лишний код
Так или иначе использование фичаветки тут решает проблему целиком и полностью
Синхронизировать вылкадки фронта и бека (особенно если они в разных репах) тоже задача не простая
Я уже не говорю о том, что нужно научить перезагружать spa с выкладкой нового кода

Получается, что задача делится на две: 1) реализовать фичу, только добавляя новые данные и не трогая старые 2) удалить ненужные данные. Это примерно как с RDBMS-миграциями, но там это понятно зачем: для возможности отката релиза. А зачем это делать в REST/GraphQL-разработке, какие это даст преимущества?

Мое личное мнение - мне он видится громоздким и не интуитивным.

Люди достаточно часто в нем путаются, допускают ошибки.

Проблема с фичами ещё - это склад старого/недописаного кода в мастере и удаление его