Often, project maintainers prefer that a single pull request be represented by a single commit. It makes the git history cleaner and easier to understand. So before your pull request is merged you’ll want to do an interactive git rebase to squash all of your commits and fix your commit message.
Now that GitHub gives maintainers the ability to squash and merge easily from the web interface, I consider asking contributors to squash to be an antipattern. I want to be able to come back after a contributor has addressed my code review and view only the changes since my last comment. If I have asked for just a minor fixup on a large PR, and they squash, I now need to hunt down that minor change in a much larger diff. Squashing also makes it easier for unrelated changes to get slipped into files in the PR that I've already "approved" in my head without me noticing. It is a rare occurrence, and I've never seen it done nefariously, but it's another reason against having the contributor self squash.
I totally agree with you. Thanks for bringing it up. This video was created before the squash and merge functionality was implemented in GitHub's UI.