Привет!

SAS>Spinifex не поленился и привел пусть и схематичный, но все же пример. Можете показать как при вашем способе это выглядит на практике?

Не увидел в примере специфики, завязанной на возможности EF. Его можно повторить на linq2db строка в строку.
Заменить unitOfWork на dataConnection (можно даже назвние прежнее оставить) и код будет совпадать один в один.
Только под капотом у репозиториев будет не EF а linq2db.

Примерный код репозитория:

class OrganizationRepository 
{
    DbNorthwind _db;
    public OrganizationRepository(DbNorthwind dataConnection)
    {
        _db = dataConnection;
    }

    public void Commit()
    {
        _db.Commit();
    }

    public void Rollback() { ... }

    public void BeginTransaction() { ... }

    public List<User> GetUsersOnTheFlat(int flat) 
    {
        return _db.User
            .Where(u => u.Room.Flat == flat)
            .ToList();
    }
}

S>... всегда могу из контекста достать данные без обращения в базу ...

Не всегда, а только если их туда предварительно положить.
И если репозиторий рассчитывает на данные из unitOfWork, то это означает появление неявного контракта со всеми вытекающими неприятностями.
Можно неосторожно забить на сложность получения данных из БД в надежде, что данные уже лежат в контексте. И получить сюрприз, когда сервис будет вызван в другом сценарии.
По мне так надежнее передавать данные между сервисами в явном виде. А если нужен долговременный кэш, то реализовать его в виде специального сервиса.

Подход с кэшированием в unitOfWork хорошо работает на учебных примерах с простыми плоскими моделями.
В реальной жизни появляются сложные развесистые документы, и внезапно оказывается, что разным сервисам нужны разные проекции одного и того же документа.
Сервису рассылки — email, а сервису начисления зарплаты — должность пользователя.
И данные, закешированные одним сервисом, не подойдут для другого.

Поэтому считаю, что в unitOfWork вместо метода Get(id), возвращающего материализованную проекцию, должен торчать IQueryable интерфейс к БД.

Кстати, вызов GetUsersOnTheFlat только для того, чтобы вытащить из базы email пользователей тоже выглядит оверхеадом.
У меня бы метод рассылки уведомлений требовал бы на входе только id пользователя, и сам вытаскивал бы по этому id из БД только данные, необходимые для выполнения рассылки.