In my opinion this is one of those "pick the right tool for the job" problems. If you have a constraint that forces you to have multiple versions in development and maintenance simultaneously then Gitflow works well. This is especially true for things with long QA cycles. If you have a SaaS business and pushed code can go straight to production after automated tests, then don't bother with the management overhead of the versions.

In personal experience... We use Gitflow for our software that ships on our IoT device where we do monthly releases and multiple weeks of QA/reliability testing. Of course, this is coupled with a slow rolling canary release process -- nobody wants customers to be forced return a device due to a bug that can't be fixed over the air.

We also use it on our mobile app and it works well. Again, this is a situation where we have to have multiple versions in development simultaneously. One in "release mode" doing critical bug fixes only as it goes through QA and internal in-home acceptance testing and one for "v-next".

Some 20 years ago we used to do roughly this same process for releasing software on CD's. But, no git back then so no "Gitflow"...

We don't use it for various services and internal tools that can get by without such rigor around versioning. Just simple branch -> PR -> automated test -> merge to master from PR -> automated test -> deploy.

Use the tool/process with the least overhead that manages what you need managed.