It's not awful, but there is room simplify it and tune it for your own needs. Using master as the develop branch is a fairly simple and sensible one. Most simpler workflows are basically git-flow trimmed down in some way. In a big team, I do like to keep release branches to isolate the polishing of the release from other development work. (Without it, teams tend to have a code freeze, which is unnecessary with a release branch.)
Because it's complicated and most people don't need that complexity at all. For some reason a lot of people happily jumped on the band wagon when this was released and started writing scripts to make it more bearable.
If you have multiple versions of your codebase that you need to maintain for a longer time to justify those release branches, gitflow might be for you. IMO GitLab flow is much more applicable for most people: https://about.gitlab.com/2014/09/29/gitlab-flow/
Because it creates a large amount of needless busywork.
It's much easier to develop on master and/or on feature branches that can be cleanly merged in to master, and then tag master (or create branches) once a release is hit.
Agree. Every git user should be aware of it and should use it on a project at least once so they know to avoid it forever after.