This is my habit and I advocate for it on new teams. It's so simple and effective. Why make it complicated?

This is exactly what we do at my job. The only time it ever causes issues with some things is when we're ramping up a new project and the PR and ticket titles don't necessarily match the work we've done. But that's more of a problem where we could make everything bite-sized, or we can deliver complete packages in terms of a feature plus all of the miscellaneous changes that we needed to make along the way to make it work. Now, is this the best way to do things? No, you should ideally make those changes separately and push each one separately. But that slows down progress.

But why not do both? I find that nice commit messages make it easier on the review to see whats going on rather than a bunch of wip commits. Then squash all of the commits into a single commit with a nice title and message. The benefits of the squash at the end are, assuming you require tests pass before merge, you have a history of commits all with passing builds which makes bisect possible.

why would you squash multiple informative commits with their commit messages and their informative context about your thought process into a single big squashed commit? git can merge branches and keep track of it, there is no need to squash unless you split trivial changes that belong together and want to group them before sharing them