S>5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.

Это весомое преимущество. Конечно я за интерфейсы. Какие еще Вы видите профиты от интерфейсов в рассматриваемом сценарии? Я вижу следующее преимущество: можно навесить логику на интерфейс IOrder (например, в виде экстеншен методов), поместить её в сборку вместе интерфейсом IOrder и использовать эту логику в десктопе и веб приложении (десктоп и веб приложение ссылаются на сборку с интерфейсом).

В случае если с десктопа и с веб приложения был бы допустим прямой доступ к БД, я бы сделал проще.
Слой доступа к данным (имеющий прямой доступ к БД) реализуем в сборке. Десктоп и веб приложение просто ссылаются на эту сборку. Если веб приложению понадобятся доп. свойства у Order в сборке веб приложения создаем наследника WebOrder : Order. Аналогично для десктопа. В этом случае интерфейс IOrder не нужен. Если кому-то понадобился непрямой доступ к БД (через сервис), оборачиваем ту же сборку доступа к данным в сервис, и тогда интерфейсы становятся нужны.

S>3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
Несколько различных реализаций IOrderService кроме тестирования может ещё для чего-то понадобиться?

S>5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.

Это весомое преимущество. Конечно я за интерфейсы. Какие еще Вы видите профиты от интерфейсов в рассматриваемом сценарии? Я вижу следующее преимущество: можно навесить логику на интерфейс IOrder (например, в виде экстеншен методов), поместить её в сборку вместе интерфейсом IOrder и использовать эту логику в десктопе и веб приложении (десктоп и веб приложение ссылаются на сборку с интерфейсом).

В случае если с десктопа и с веб приложения был бы допустим прямой доступ к БД, я бы сделал проще.
Слой доступа к данным (имеющий прямой доступ к БД) реализуем в сборке. Десктоп и веб приложение просто ссылаются на эту сборку. Если веб приложению понадобятся доп. свойства у Order в сборке веб приложения создаем наследника WebOrder : Order. Аналогично для десктопа. В этом случае интерфейс IOrder не нужен. Если кому-то понадобился непрямой доступ к БД (через сервис), оборачиваем ту же сборку доступа к данным в сервис, и тогда интерфейсы становятся нужны. Но в этом случае логику на интерфейс IOrder уже не навесишь (как я выше написал), так как она уже в классе Order присутствует. Но я сторонник прямого доступа к БД с дестопа. Да, надо поработать над безопасностью и правами доступа на уровне БД, но дело того стоит. Не надо создавать сервис доступа к БД, только для того чтобы не возиться с её настройками безопасности.

S>3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
Несколько различных реализаций IOrderService кроме тестирования может ещё для чего-то понадобиться?