like 90% of developers (maybe 95%) don't even know how to rebase from master before they submit a PR, so I doubt, highly, that they'll learn how to do a `git rebase -i` in order to make things cleaner. I've personally never seen a repo that utilizes all these "fancy" git commands (fancy to those developers) to make a clean history, I've always seen the messiest shit. Maybe that's sad for me in my career, though.
I agree with you this is the best technical way, though, after reading some more comments in here, but not the best way for everyday developers.
This is why you use rebase --interactive or other ways of amending commits before submitting a PR. It is not an argument for commit squashing.