Composition tends to lead to more code reuse. And to more code that's still usable in unpredictable future.

Over time your whole inheritance model often turns out to be no longer viable, when the basic assumptions made years ago are no longer valid.

Worse, because of all of the accumulated cruft, you might not even be able to change the shape of the monster.

In go, composition has a special feature where if you include another type anonymously in a struct, the methods of that type are automatically available for the struct as well. It is also possible to "override" these methods at the struct level and call the anonymous member directly.

So you can get some of the conveniences of inheritance. The behaviour is of course different, because the composed member has no way of knowing the identity of the including struct.

Composition should lead to clean components for reuse. You might need some extra references, but it is more explicit, static and flexible. Inheritance sounds great in theory, but is a hierarchical blind-alley, though usable for static designs that never change much.

I don't see that composition should be cause for repeated code blocks.