When picking a git workflow, you should start with your system's and your team's requirements in mind. Don't just copy git-flow or GitHub's simplified version.
Not every team or system uses pull/merge requests at all. Some do pull requests to the development branch, and to master when releasing a new version.
In some teams, code review is the bottleneck, and a developer may have to create a new branch from a PR to keep developing while waiting for code review, then create a second PR that builds on top of the first.
This last workflow is the main reason why I'm opposed to squashing PRs. It just doesn't work.
Also, squashing my carefully composed commits with individual references to DevOps backlog items is insulting.
Not every team or system uses pull/merge requests at all. Some do pull requests to the development branch, and to master when releasing a new version.
In some teams, code review is the bottleneck, and a developer may have to create a new branch from a PR to keep developing while waiting for code review, then create a second PR that builds on top of the first.
This last workflow is the main reason why I'm opposed to squashing PRs. It just doesn't work.
Also, squashing my carefully composed commits with individual references to DevOps backlog items is insulting.