Only the logic for application business rules should be in use cases; changes to the UI should not change how a use case is implemented. To me, it seems like a combined LoginAndDownloadAttachmentUseCase
would only be useful in the context of a specific UI, and therefore should not exist as a use case.
Also, if you were to create combined use cases for all possible scenarios, it would lead to a combinatorial explosion of use case classes as your app becomes more complex.
It's ok to have some logic in ViewModels, especially if it's just transforming data or doing high-level operations. Each use case represents a single high-level operation. Having the ViewModel stitch together a few of these does not make testing and maintainability more difficult.
I think https://github.com/googlesamples/android-architecture/tree/usecases is a good example. The use cases are pretty slim, but in more complex apps, they could combine several datasources together.