I've switched from adding many commits in a single feature branch to adding just one and amending it. It has its pros and cons, it's worth to know them.
Rebase
A single commit is easier to rebase. I don't struggle with conflicts for each commit in your branch, I just do it once and it's done. This is useful when merging to main, but also when I need a feature from any other feature branch.
Signature
Having multiple commits squashed on merge to main causes this squashed commit to not have your signature. Each single commit I create locally has one if I sign them. The squashed commit however is not produced on my machine, it never saw my private key and in the main branch's history it's not signed by me.
History
Keeping with the best git practices you'll have atomic commits, one for every little change. This granularity of history is a mess in your main branch so you should either squash the changes or amend them to just one commit.
Review
Addressing the changes after the code review is more challenging for the reviewer if they all come in one commit. When I introduce changes in a commit it's still the same commit, they can't just review last changes. However this problem is mitigated by some repo services, for example Gitlab has a nice versioning feature that lets you see different versions of one amended commit during the review.
What I did and do now
I was used to atomic commits, but that's changing now. I find making atomic commits and then packaging them all into one just when I need it to interact with the rest of the repo (merge, rebase, whatsver else) a good transition technique. Over time I was chosing amending rather than new commits more and now it's natural. Just like when I've been changing merges for rebases.