Тогда получается у него 2 причины для изменения - это

Получение анекдота и метод ускорения (в данном случае кэш). Но мне не сильно понятно что за сервис анекдотов

Это выглядит само по себе как репозиторий

Ну тоесть сервис кэша не может вернуть неверные данные. Это не его уровень ответственности. А сервис который обрабатывает какие-то значения не должен заниматься ошибками получения этих значений. Возвращаясь к первоначальном твоему сообщению - проблема множества моков это не проблема тестов, а твоего кода.
На сейчас же получается с твоей наркоманией ты тратишь уйму времени на написание тестов (описывать 2-3 мока на один сервис эт пипец), а как следствие того что ты параноидально тестишь все возможные варианты - у тебя хрупкие тесты. Получается ты очень много времени тратишь на  тесты.

Да. Я трачу на тесты больше времени. Но это окупается меньшим количеством непредсказуемых ситуаций

На счёт похожести на репозиторий. Ну пусть там в сервисе будет спец алгоритм ранжирования входящий через интерфейс. И кеш для каких либо значений предгенерации или типа того. Вариантов можно придумать массы когда в сервис лезет 4-5 интерфейсов каждый из которых может иметь сайд эффекты при реализации. И если вы не хотите чтобы ваш сервис падал на каждый непонятный чих со стороны реализации интерфейсов вас просто необходимо предусматривать все ситуации.

Это если смотреть с точки зрения реализации. А вы смотрите с точки зрения актора. И будет всегда одна.

Срп трактуется по-разному. Сильно по-разному.

Часто это объясняется неграмотностью

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

Масса примеров где простая идея (например user story) обрастает булшитом

И что говорит нам источник ? СРП - класс должен иметь только одну причину для изменений.

Есть класс сервиса который берет данные из хранилища и передаёт их на обработку алгоритму. Результат возвращает.
Алгоритм и хранилище это интерфейсы.

сервис анекдотов выглядит как анекдот

Вы можете вместо анекдота выбрать любую другую сущность. Разницы не будет.

И где тут хоть что то про срп?

Где анализ причин изменения?)

Я не вижу там нарушения срп. Если вы видите - аргументируйте.

Class PopularEntriesService
   Function analyze(AlgorithmInterface, EntriesRepositoryInterface, SettingRepositoryInterface)

AlgorithmInterface->init(SettingInterface->get)
Return AlgorithmInterface->analyze(EntriesRepositoryInterface->get)

На это кусок кода нужно накидать как минимум с десяток тестов если я хочу чтобы сервис был стабилен. Даже если реализации протестированы по отдельности
Потому что сервис не может знать какую зернь выкинет реализация.

А где ту нарушение срп для сервиса я не понимаю