Whenever people try to argue that small and meaningful commits do not matter, I introduce them to git bisect. I’ve yet to meet someone familiar with it that does not agree.
I have burned hours upon hours on rebase conflicts over the years.
I have settled on squash merging feature branches into main and no force pushes on anything shared, ever.
Hate to say, "You're using it wrong", but if you haven't repeated conflicts rebasing, then your commits are probably just not small enough.
A merge does not magically eliminate any of the conflicts either, you just do them all at once rather than point by point. And the smaller the changeset, the less likely you will have any conflict at all.
Small changes, sorted lists (so parallel additions rarely conflict), allowing trailing commas (again to allow for parallel addition), splitting dependency updates from structural changes (to allow wholesale removing them if they were done separately), ... there's plenty of little changes to how you put together work that make this workflow easier.
Likewise if multiple iterations on those lines were made upstream while your feature branch exists.
Fundamentally expending any effort to find a coherent combination of two pieces of code where one of them you know isn't going to remain is a waste of time.
The only advantage would be if those incremental changes actually make it easier to arrive at the final merge of the last changes on each branch but I'm not sure your above tips really guarantee that. IME it rarely happens.
It's one of those things that sounds super cool and advanced and i thought id be using all the time when i first learned about it but in practice 99/100 times to see when and where to bug was introduced it it's quicker and easier to just track it down manually in the code.