Hmm. I think I disagree. One can clean the commit history to look like that, but it's optional. You can merge all of your messy starts and restarts right into master if you want. Easier to do, in fact.
I don't understand the desire to squash every PR into one commit each either…
If you want to amend commits for a typo, code style fix, or otherwise inconsequential change that doesn't add any useful context for future developers, by all means go for it.
It is very difficult to read the commit history and get a sense of anything except Jira issue codes.
One needs to look at the individual files and read the code to understand what the commit was for.
This forces individual programmers to think somewhat carefully about leaving a sensible commit history behind.
On a feature branch, whether you constantly rebase against master or merge from master probably should depend on the nature of the feature branch and what exactly has been happening on master. And it ultimately doesn't matter that much.
In my experience, as long as branches are ultimately merged to master with --no-ff, you can almost always recover a sensible commit history, and you should almost always end up with a sensible, tidy master to base new branches off of. If you rebase with squash/fixup on the feature branch before merging, all the better, because then you get nice "meaningful" commits on the feature branch. But even if that doesn't happen and the feature branch is a mess, at least you could write a meaningful merge commit message.
Maybe things get hairy with huge teams or huge projects that could necessitate a different workflow. But most developers are not working on projects like that.
I wish this workflow was better supported but since it isn't most people just default to squash and merge or rebase and merge.
the community in fossil is in favor of accurately recording history.