Давайте продолжим.

Какие могут быть недостатки у подхода gitflow?

1. Множество долгоживущих веток.
Две очевидные "вечные" ветки - master и develop 🟡.
При этом фича-ветки в классическом gitflow тоже не ограничены по времени жизни. Разрабатывайте свою фичу хоть три года, куда спешить.
Если релизные ветки создаются под каждый релиз и потом закрываются, это еще полбеды. Совсем плохо, когда команда проекта использует отдельную долгоживущую ветку releases 🟢 просто потому, что они так поняли картинку, но текстовое описание флоу не прочитали 🤦‍♀️
Это могло бы показаться шуткой, если бы не повторялось десятки раз

2. Неоднозначность разрешения конфликтов.
Конфликты при объединении веток неизбежны и рано или поздно случаются. При этом то, как такой конфликт разрешается - на совести разработчика, решающего конфликты вручную. Тот, кто хоть раз сталкивался с подобной задачей на большом объеме кода, знает, насколько хрупко равновесие проекта в этот момент 🤞

На картинке, если коммит из hotfix 🔴 попадает в develop 🟡 с конфликтом из-за того, что там уже произошли какие-то изменения после релиза, то это неизбежно приведет к расхождению master 🔵 и develop 🟡 с непредсказуемым результатом в будущем.

При использовании gitflow обычно к каждой ветке привязано свое окружение и этим объясняется необходимость долгоживущих веток. Например, весь код из develop 🟡 собирается и попадает на стенд разработки, из releases 🟢 - на stage для тестирования, из master 🔵 - на продакшн. Вроде бы логично, понятно и удобно, если вас не смущает то, что на стейдже вы тестируете один код, а на продакшн выкладываете другой 🤷