Как раз молодые разработчики усложняют (они чаще плодят сущности, подражая, а не думая).
А вот специалисты с опытом упрощают. У упрощения два основных подхода:
1. Не делать того, что не требуется.
2. Разделять и властвовать над тем, что требуется. Правильно разделяя - мы упрощаем.
Что касается репозиториев. Объекты бизнес логики не должны знать где и как они хранятся, как извлекаются и сохраняются. Тогда бизнес логику легко написать и протестировать. Так же легко мы можем протестировать отдельно извлечение или сохранение объектов. Что ведёт к лёгкой смене хранилища. И при этом нет стандарта на репозитории и их интерфейс. Он может быть минимальным и добавляться на основе востребованности. Не нужно сразу писать интерфейс на все случаи жизни.
Порой случается, что бизнес логика простая. Взять объект из одного места и положить слегка изменив в другое. Вся сложность будет не в бизнес логике, а вокруг неё. С репозиториями. Один репозиторий реализует только извлечение в общий вид объекта, а второй только размещение в хранилище. И мы знаем, что если изменится API для какого-то из хранилищ, то изменения придётся вносить только для него. Мы разбили и скорее написали больше кода, но зная, что один API сырой или быстро изменяется, мы защитили себя от сложности внесения изменений.