Not the OP but with my own personal usage, sometimes I'll end up with multiple related commits where I've had to go back and fix a test or correct an issue I missed with an earlier commit. Therefore I commit and squash that into the earlier commit with related changes.

I don't buy that every change should be a separate commit - if changes are related and the commit message covers the changes it makes sense to squash.

Not sure if OP is talking about squashing all commits into one. I have seen people do this and I'm always a bit confused why, similar to your point.

ok depends on the size of a feature I guess but usually I sit in a branch for 2-3 days before I finish the feature.

Also what's the point of preserving the history of a branch that is used for the development of a requested feature ? For each commit before the final, the feature is incomplete, possibly not working at all.

Not everyone is a believer in shippable increments, but it is a good practice nonetheless. (not necessarily fully working)

Splitting per feature is indeed ok if it is small including effects on dependencies. But in my practice there are rarely small enough features - these map to something akin to user stories which have to be further broken down.