Наоборот и если нет то почему, и если да то почему

какие есть ещё случаи?

можно на код взглянуть?

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

в простых CRUD-приложениях сервис действительно частенько просто проксирует все методы к репозиторию. отсюда, вероятно, и непонимание, зачем разделять. в более сложных сервисах бизнес-логика может вызывать 10 методов 5-ти разных репозиториев и еще пару внешних сервисов по HTTP. Тут уж никакого отношения 1 к 1 нет.

Это не мой подход, свой подход и мнение я написал выше, где да по смыслу интерефейс добавляет гибкости

Да, увидел, с ним согласен

я видел такой код и в простых и  в сложных приложениях, опять же  мое "понимание", разделять не разделять, мое мнение выше)

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

Я тоже нихрена не понял)

Нужен, в любом случае

))))) Все просто, в классическом нашем понимании UserRepo  -> UserService -> UserServiceImpl

это качественнее

чем без UserService

что означает "->"?

кто как

Это вы из тех кто на каждый класс создаёт по интерфейсу?)

Достойно Безухова