Архитектура репозитория против архитектуры клиент-сервер?

Я бы не согласился. Репозиторий, безусловно, является способом реализации паттерна клиент-сервер, в частности, на стороне сервера. Наличие сервера подразумевает наличие клиента, по крайней мере, одного. Даже если где-то нет централизованной базы данных, все равно существует уровень данных, который может быть локальным для клиента. Без некоторого типа уровня данных вы ограничены только приложениями «в памяти»: у них вообще нет состояния (включая, например, отсутствие пользовательских настроек). Я предполагаю, что ваш вопрос не ограничивается теми.

Идея остается за шаблоном репозитория — это необходимость абстрагироваться от деталей реализации ввода-вывода данных. Он скрывает определенную структуру базы данных, ее конфигурацию, отображение и (редко) логику проверки внутри соответствующего класса IRepository. Обычно эти ребята являются общими, поэтому программисты имеют дело с IRepository<T> с некоторыми дополнительными ограничениями, наложенными на T. Таким образом, наличие такого интерфейса позволяет вам: 1) одновременно использовать концептуально разные базы данных, сохраняя другой код в неведении об их принципиальных различиях (представьте себе традиционный SQL вместе с базой данных на основе графов), 2) заменять разные базы данных без внесения изменений в внешний мир: скажем, вы решили избавиться от MSSQL и перейти на Neo4j или наоборот, 3) наконец, последнее, но не менее важное, вы получаете острую грань некой «ответственности» — ввод-вывод данных. Это действует как удобная точка расширения для внедрения расширений, таких как проверка или ведение журнала.