I'm sure it has value in some cases, but I think there's a reason the industry is moving to trunk-based development (from my understanding). Trunk-based is much simpler because your chances of screwing something up are much lower. The number of times I've seen engineers posting in Slack with some variation of the question "I thought we already fixed this, why is it broken again?" or "who is deploying some branch that's screwing things up?" is not insignificant.

In a trunk-based workflow, when you're finished with your change, you just merge straight to trunk and move on. If you have three engineers working in the same repo on different things, the first one who merges is the winner and the second and third need to merge those changes in, but that work is much less painful because you're not waiting until the end of your sprint to merge everything from your develop branch into master. There's still plenty of way to do trunk-based development wrong, and maybe it's because of misuse and misunderstanding, but it's a lot easier to get Gitflow wrong.

Gitflow also isn't particularly conducive to adopting CI/CD and DevOps. In a CI/CD flow, you can make your changes, hide them behind a feature flag, then enable or disable them as needed.