VolCh

Тут он исполняет роль некоего подобия репозитория, а не представляет собой конкретного пользователя, предназначен для использования методов типа $user = $this->user->find($request->get('user_id')), $activeUserQuery = $this->users->newQuery()->ofActive() и т. п. По хорошему свойство и параметр $users надо назвать.

В конструктор внедряется репозиторий, а в методы конкретные пользователи.

Правильное направление. Но полностью до SRP ещё далеко. Например, наличие в сервисе вызовов \request() говорит об отвественности сервиса парсить суперглобалы. Да ещё с помощью не очень явной зависимости.

По хорошему контроллер вообще не должен работать напрямую с моделью, а только с сервисами. Его основная ответственность — адаптировать параметры своего вызова в вызов сервиса, а результат от сервиса в свой результат. Модель должна дергаться уже в сервисе.

Что должно быть в самом сервисе, а что сервисом делегироваться в модель (сущности) вопрос не простой в общем случае, но основной принцип — у модели не должно быть зависимостей, кроме других моделей и чистых функций типа стандартных функций математики или работы со строками/массивами. Прежде всего не должно быть зависимостей от инфраструктуры типа файловой системы, внешних апи, переменных типа $_FILES или оберток для них типа request().

Сущность — ресурс, правильно. Например, ресурс /articles/1 представляет собой сущность класса Article с идентификатором 1. Но кроме ресурсов, представляющих сущности, есть ресурсы, представляющие коллекции сущностей, например /articles. По хорошему вообще надо разделить контроллеры на ArticleController и ArticleCollectiontController, где первый управляет представлением сущности, а второй списка сущностей. Но обычно во втором тогда будет только пара методов для GET и POST, вот и примешивают их к первому.