> I intentionally don’t want my half-broken commits to be in the production branch.

That makes no sense. What does it matter that interim versions from a merge might not work, what matters are the milestones like merges and tags. Basically you're imposing a silly aesthetic restriction on what's supposed to be a functional tool.

The whole argument feels a bit People's Liberation Front of Judea to me. On the other hand I do have strong views on the matter, and I am pretty certain that my views are pretty close to the correct ones.

My silly aesthetic restriction is ‘tests pass’ and my branch commits don’t have this quality in all cases.

Apparently what you do makes sense for you, but I hope you realize that using interactive rebase you can turn your half-broken commits into nice and clean commits!

I try to do this as I go, but there is always a "history review and fix if necessary" stage after I've got the code I wanted and before merging.

Apart from having granular, reviewable, bisectable history, there were many a time when by having this extra look at the code I found bugs or design flaws.

Whether such effort is worth it for you, and whether you have time\energy\discipline\skills for it is a different question.