My experience has been the opposite. Every organization I worked at used Trunk based development (feature branch->master). Because branches are short lived and usually small, they are the atomic representation of a change, and not the commits in the pull request. Pull requests usually have lots of "linting", "fixing test", "fixing typo" commits that I absolutely do not want in my master branch.
I understand that not all organizations work like this, but that is my point: there is nuance. Blanket statements like these are not productive. The author seems frustrated that people still use squash merge, and just assumes that it's because people just don't understand how git works.
I understand that not all organizations work like this, but that is my point: there is nuance. Blanket statements like these are not productive. The author seems frustrated that people still use squash merge, and just assumes that it's because people just don't understand how git works.