For years I reached for an abstraction before I had more than one use case. A helper, a trait, a base class, something to hold the shape of what I thought was coming. It felt responsible. It felt like architecture. It was mostly anticipatory complexity.
The problem with abstractions written before the second use case exists is that they model the future you imagined, not the future that arrives. When the real second use case comes, and it's never quite the one you expected, you end up bending both the abstraction and the new code to fit each other. More work, less clarity than if you'd just written it twice.
So I write the duplication. Two classes that do similar things, three functions that share a pattern. I let the code stay concrete until the right abstraction becomes obvious on its own.
An abstraction earns its place when removing it would make the code harder to understand. Feeling tidier doesn't count.