Зачем использовать варианты использования? Android Jetpack не упоминает варианты использования в документации

Если вы хотите строго следовать чистой архитектуре дяди Боба, вам следует использовать варианты использования.

They are accessing the repository directly from the ViewModels. Isn't that a better option?

В значительной степени это зависит от того, что чистая архитектура делает тестирование очень простым, а также заставляет вас мыслить более архитектурно, прежде чем что-то внедрять, и заставляет вас не идти на компромиссы, известные как корректирующий код, и она следует принципам SOLID, которые просто великолепны.

С другой стороны, гораздо сложнее настроить проект, и иногда кажется, что вы слишком его проектируете.

Но после его настройки вы увидите улучшение ремонтопригодности, а также масштабируемости.

Я думаю, что здорово знать, что такое чистая архитектура, и брать то, что соответствует вашим потребностям.

Это отличный ресурс, если вы хотите узнать больше о чистой архитектуре https://caster.io/courses/android-чистая-архитектура и о том, как она подходит для Android.

Ну я думаю действительно не обязательно использовать UseCases, особенно если вы с ними не знакомы. UseCases — это просто архитектурный шаблон для создания более масштабируемого проекта и повторного использования кода.

Я лично использую UseCases, когда вижу, что это имеет смысл. Например, в нашем проекте у нас есть View, ViewModel и Repository. Два распространенных случая использования UseCase: если

1) Two ViewModel имеет общую логику обработки данных из Repository. Это может превратиться в UseCase (но не обязательно, вы можете создать VM меньшего размера для этого)

2) Вы хотите включить плюсовой слой между Repository и ViewModel, потому что вам нужен этот слой для обработки дополнительной логики, которая не предназначена для Repository и/или ViewModel. Например, ни Repository, ни ViewModel не должны решать проблемы планирования. (проблема типа, если у вас кеш получить данные по Основная нить, если нет переключиться на фоновый поток.)

Итак, в заключение, ничего связанного с архитектурой не нужно. Вы не должны навязывать что-то в своем проекте, архитектурные шаблоны существуют только для того, чтобы упростить изменение, масштабирование и работу с вашим приложением.