I have used gitflow successfully for some time (starting when it was first announced and there wasn't anyone complaining about it). I've always done "develop is always deployable to production" and the only thing we used master for was rolling back (extremely rare), and the only thing we used release branches for was demos or documentation before a release went out. We had CI built against develop but also every feature branch and every PR. We also leveraged static analysis the same way, and at one company even ran automated pen tests on develop and PRs.

I don't know if I fundamentally misunderstood gitflow but this was my take on it from the beginning and I've never had issues with it that made me want to jump ship.

We didn't use hotfix or support branches, and we never really used tags for anything either. Not using them didn't cause any noticeable overhead.

The nice thing about git-flow in my opinion is that you can implement it without all of the CI stuff, then add that later over time. This is a godsend when you take over a legacy product with little to no test coverage and no CI pipelines.

I've also never run into a ton of merge conflicts, but the largest team I've had is 70 people so maybe it breaks down at some point that I haven't experienced yet.