Favour happens when both candidate qualifies. The problem stated in the question fails on this account, because it only has a composition option.
"Composition could use generalization as well". Does this statement make sense to us? If not then we are not yet ready to grasp the 'favour' rule.
Why we are favouring Composition is that Composition offers more extension/flexiblity possiblities than generalization. This extension/flexiblity refers mostly to runtime/dynamic flexibility(which is achieved with the combination of interfaces and composition).
The benefit is not immediately visible. To see the benefit you need to wait for the next unexpected change request. So in most cases those sticked to generalization fails when compared to those who embraced composition(except one obvious case mentioned later). Hence the rule. From a learning point of view if you can implement a dependency injection successfully then you should know which one to favour and when. The rule helps you in making a decision when you are not sure which one to choose. Again you should be able to see both options in the first place to favour one.
Summary: Composition :The coupling is reduced by just having some smaller things you plug into something bigger, and the bigger object just calls the smaller object back. Generlization: From a 3rd party API point of view defining that a method can be overridden is a stronger commitment than defining that a method can be called (sure win for Generalization). And never forget that with composition you are using generalization too, from a interface instead of a big class. But the whole credit goes to composition unfortunately.