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

у Вас получается , что разные сущности можно сохранять в одном репозитории , это совсем проиворечит всем правилам

и при этом репозиторий еще должен уметь все возможные сущности обрабатыать

Почему протеворечит?

Где те правила?)

Что один репо на 1 сущность

ну , потому что смысл теряется , во первых придется этот репозиторий переписывать каждый раз , зачем ?

А писать новый репо каждый раз на новую сущность лучше?

разумеется , один репо = один тип сущности , появляются новые сущности - расширяем перечень репозиториев без изменений в истеме

ну а интерфейс может быть общим , только такой IRepository<T>

ну я работаю с ЕФ, гвооррю же, мне так проще. У меня появляются сущности, а репо не изменяется

хоть миллион сущностей будет, репл как был 100 строк так и останется

единственно что инклюды бывает нужны для обхода lazyload

ну , тогда Вы название паттерна используете не по назначению , это все что угодно , но не реализация репо )

и жестко зависите от EF

Я не вижу разницы создавать новый репо каждый раз для новой сущщности или дописывать класс репо, как по мне равнозначно)

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

В конкретно этой реализации нет. Но достаточно сделать T: ISomeEntity и все

Тогда вы автоматом можете сохранять только определенные сущности, удволетворяющие неким правилам

да , но тогда тут же гибкость теряется )