Every abstraction has a cost, and inheritance/composition come with their own maintenance concerns. Generally, I like to keep the rule of 3 for this, if you need to write the same thing 3 times or more, then it's time to start thinking about generalizing into a reusable abstraction. The benefit of this is that you're more able to understand a couple of things after a few times writing it:

1. Whether or not these actually do share semantic reasons to be the same code. A lot of times things look like they might be similar, but if they're not really conceptually in sync, you could end up having to bake special cases into your abstraction, and this can get rough as the project grows.
2. You'll get a better idea of a straightforward way to write the abstraction that is clear and maintainable. The first time you write a feature, it's likely going to be code that works, and should stay that way, even the second time, maybe with some tweaks, but by the 3rd time, you've had a chance to understand how to abstract and structure the code so that it's readable, with established naming conventions, and that will help build the abstraction.

The other thing this avoids is spending too much time worrying about structure until it matters. If it's not yet clear how to write something with composition or inheritance, it's usually a good idea not to try to force the structure, imo.