"A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after."
In my experience, new/small teams do well if they stick the "Scaled Trunk-Based Development" model until a legitimate reason to deviate is discovered (e.g. needing to back-port changes to an older release may imply making commits to non-trunk/master branches...).
I default to recommending either Github Flow[0] or Gitlab Flow[1] these days.
Both of these models simplify Gitflow by dispensing with the long-lived development branch and therefore the complication of needing separate hotfix vs release workflows.
The difference between these models is that Github Flow expects you to deploy to environments within a pull request before merging to master, whilst Gitlab Flow expects you to merge to long-lived environment branches for deployment (presumably using Gitlab's CI features).
It's of course possible to have a meaningful discussion about different types of branches, releases, changes and about what changes should be merged, when, and where, but ultimately there is only one good branching strategy: thinking.
Thinking about the purpose of branches, thinking about whether everybody is on the same page and what mistakes are possible, thinking about useful rules about changes and merging (possibly on a branch by branch basis), thinking about when to break and how to adapt the rules, and above all thinking about the objective of making correct and low-effort merges.
Adopting practices because a blog post says so is the opposite of maturity. As Gitflow is presumably a good fit for the project it originated in, any "alternative styles" are suitable for someone else's particular needs and should be treated as examples and anecdotes illustrating general principles.
