Not the original commenter but this felt worth adding to: you mention 'cargo culting', yet there are already two comments raising the core benefit, which is keeping main 'stable and working' while develop stays 'rough and ready'.

A less rigid development branch allows feature branches to be smaller and easier to merge, and keeps developers working against more recent code.

A more locked-down, PR-only main branch enables proper testing before merging, and ensures that the feature and release branches stemming from it start in a cleaner state.

I've worked with both approaches and I'm firmly in the camp of keeping main stable, with a looser shared branch for the team to iterate on.

Right, I get what you're saying, but in git-flow, the master branch isn't just "stable", it's "literally the last release we made". Which you can also get from the tags (i.e. checking out master or checking out the highest numbered release version tag will give you exactly the same commit). So I'm not sure I see the functional difference. Either you have "develop is messy, master is stable", or you have "master is messy, latest release tag is stable". I mean, sure, there's a bit of mental work involved in "which of these tags has the highest number". But surely that's less than the work involved in maintaining two long-running branches instead of one? I'm not really arguing for one way of working (or level of stability at integration) or another, I'm arguing that the one that git-flow supports can be implemented in a functionally equivalent, but simpler way, with naming that is more consistent with usage elsewhere.