Kind of late to the party but UseCases calling other UseCases is a bad idea. UseCases scale not vertically(should not have dependencies on other usecases) and should evolve separately from each other. In an architecture that promotes usecase inside usecases you will have a hard time finding the the base usecase where it all boils down to if they are nested within eachother. You can also run into some bad cyclic dependencies down the line if you have usecases trying to call usescases, that call usecases within each other that depend on the same usecase(you get the point).
You can end up with tens of usecases being nested in each other. So a good rule of thumb is to have one usecase per requirement. The UseCase is nothing but a user story, it should be an independent entity, free of other usecases, as it can evolve over time.
It also promotes parallel development. For example me and you can work on our separate tickets and user stories. If you were to use my usecase, and I change something in mine then yours will fail. And think about this scenario with hundreds of devs and usecases.
DRY should be applied to ideas, not code.
Also Uncle Bob covered this already -> https://www.goodreads.com/quotes/9579416-but-there-are-different-kinds-of-duplication-there-is-true
Even if code appears to "duplicate" across usecases, it is okay, because over time they will evolve and become totally different, even if it is not apparent now.
This is also a good read on this topic:
