The biggest trap of a poor abstraction is failing to recognize that, even though they may look similar, two repeated pieces of code aren't necessarily intrinsically the same thing.
And when you create abstractions without considering this, you end up making the logic rigid and coupled, which will inevitably lead to patches and hacky solutions when the code pieces that seemed to be the same thing require different paths, precisely because they have different essences.
This is also why early abstractions are so discouraged: 'early' means that perhaps the ideas, domains, and responsibilities of what you're building aren't yet clear, so the essence of each thing isn't clear either: it's easy to mess up.
It makes sense, then, to understand why the single responsabilty principle exists and is popular. It's harder to 'get it wrong' when you focus on solving a single specific problem, where things are more clear and less complicated.
Low-level abstractions are usually more coherent, due to their specificity, and therefore have more clarity.
High-level abstractions are much more sensitive precisely because of the complexity and difficulty of how things interact, their natures, and different use cases.
Therefore, when you feel the need to abstract something because you think you're repeating a lot of code, logic, and dealing with many boilerplates, don't fall into the trap of wanting to create a 'complete abstraction that will solve everything I need'. Focus on identifying certain patterns and create abstractions that specialize in solving that exact specific problem. Over time, you'll be able to remove complexity by delegating specific problems to your 'specialists'.
NoteThe text above was originally tweeted in pt-br.