The important problems to solve are all social: how do you divide the work, how people talk to each other when working on the same code, etc. If you solve those right, your team can be successful with any git workflow, and if you solve those wrong, they will fail despite any git workflow.

After you get the important things right, the will exist relevant optimizations on the workflow like those on the article. But they won't make or break your team, and will certainly depend on a lot of details so any universal preaching must be taken with care.

I led a team of 20 devs using this approach. It worked very well. No one stepped on each other's toes. The advantages noted in the article are so true. Avoiding feature branches was a game changer for us. Move faster with much less stress.