I can see where the author's coming from. However, my approach for a PR might be a bit of a mix. Normally, I aim to make a PR be reviewable, commit by commit. However, in some cases, due to a semicolon missing (you get the point), or some instance where I'm being daft, or me bumbling in the dark trying to fix a piece of ancient, undocumented code, the history might end up being less than clean. The messages will always describe my train of thought in those scenarios, but the overall history wouldn't be cut and dry.

I tend not to worry about that and generally just squash the commits when I merge, so that, on main, there's a single commit for a particular feature. That's an overall piece of work I did. If someone wants to dig into a feature commit by commit, they can typically check the PR out and do it that way, but in practice, I've rarely seen that happen, and if it did, it was more for the overall feature rather than any one commit.

So, overall, it's not that commit messages don't matter, but rather that, while a pristine history is always nice to see, it's not always possible without unnecessary head scratching that generally just costs more dev time for very little benefit.