From https://go-proverbs.github.io/: A little copying is better than a little dependency.
Curious to see how the community is divided on this, I think I'm more leaning towards the single implementation side.
To the author's point - a wonky param to control code flow is a clear and glaring sign that you consolidated something that wasn't actually the same.
The similarity was a lie. A mistake you made because young features often have superficial code paths that look similar, but turn out to be critically distinct as your product ages.
Especially with modern type systems - go ahead and copy, copy twice, three times, sometimes more. It's so much easier to consolidate later than it is to untangle code that shouldn't have ever been intertwined in the first place. Lean on a set of shared types, instead of a shared implementation.
My future self is always happier with past me when I made a new required changeset tedious but simple. Complexity is where the demons live, and shared code is pure complexity. I have to manage every downstream consumer, get it right for all of them, and keep it all in my head at the same time. That starts off real easy at shared consumer number 2, and is a miserable, miserable experience by consumer number 10, with 6 wonky params thrown in, and complex mature features.
---
So for me - his rule of thumb is egregiously too strict. Consolidate late and rarely. Assume the similarity is a lie.