One of the challenges of git a decade ago was that people created branches everywhere and it became difficult to reason about what branches were doing and what work should be done in them.

Git flow, at that time was the most reasonable model for git branching.

By reasonable I mean "able to be reasoned about". If I see a feature branch, I know what should be in it. I know what should be in a release branch. I know what the state production is in.

It isn't the best branching model - but when faced with the contemporary other branching models, git flow let was an attempt to put some order to that.

It also works fairly well. It isn't so much that its dogma, but rather that it is consistent and understood across different teams. The problems that it solves in communication are more important in many places than the ones that it causes in other parts of the workflow. Coming up with a new workflow isn't hard - just that one now needs to solve a different set of problems and most people don't want to have to solve those problems... and so git flow is an acceptable default.