Как ServiceStack помогает поставить разработку веб-сервисов на поток

Под Linux есть проблемы с производительностью, утечками.
Но фреймворк замечательный, да.

Я бы еще добавил упоминание Swagger плагина

Да уже одно требование по лицензии- сразу минус. Не потому что бедные мы, а потому что на распробовать не хватит.
Hello World- писать всегда легко, а дальше обычно начинаются подводные грабли.

Rest/Soap вместе на базе одного сервиса- как минимум странно, как максимум плохо. Это два разных принципа построения Api. Один — манипуляции с ресурсов, второй по сути Remote Procedure Call. Если они мешаются, значит что-то явно не так.

Хостинг на Linux- вообще-то Asp.Net WebApi тоже прекрастно хостится там, не совсем из коробки, но можно.

Я ни в коем случаи не против этого framework, и даже его пробовал… просто ваши аргументы- не аргументы.

ServiceStack действительно пожалуй луший фреймфорк, что есть на платформе .net, для создания полноценных RESTfull сервисов. У него много разных возможностей, и по производительности отдельных компонент он уделывает большинство своих конкурентов. Взять хотя бы ту же json сериализацию — http://mono.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.1000000-times.2010-02-06.html или OrmLite — https://code.google.com/p/dapper-dot-net/

Однако у него на текущий момент есть много других «недостатков», которые приходится решать нестандартными методами.

• нельзя делать более сложные Route, чем test/{f}/{fd} — маршрут {tr}-{tr} уже не пройдет (как пример: ru-RU)
• В отрыве от всего фреймворка сложно использовать его IoC контейнер — приходится извращаться.
  Например, если требуется выделить слой DAL на основе встроенного OrmLite и связать его со слоем бизнес логики (а эти все компоненты в других сборках) — то просто получить доступ к контейнеру IoC не получится, а это значит что большинство функций контейнера не доступно. Например нельзя вызывать нигде TryResolveNamed (даже в классе Service), хотя зарегистрировать можно.
  Опять же IoC настолько упрощен, что отсутствуют некоторые весьма востребованные вещи — например управление жизненным циклом объекта.
  
• Вмешаться в процесс сериализации задача не тривиальная — внутренний сериализатор настолько упрощен, что, например, обертку вокруг данных приходится делать для всех классов. Просто так получить json вида response {тут описание объекта} очень непросто. Это можно было бы сделать какой-нить настройкой или атрибутом для класса — однако такая вещь отсутсвует. Т.е. если использовать простые описания классов, то для того что бы получить унифицированный вид ответов от сервисов — надо описывать доп контейнеры.
  
• В системе автодокументации тоже много мелочей, из-за которых сложные оисания сделать не просто. К примеру, если в шаблоне задан путь /v1/entities/{params} то пресловутый свагер, будет считать что наша сущность это не entity, а v1.
• перечень не полный, выделил те, с которыми наиболее серьезно столкнулся...

Ну и конечно 4 версия внесла много изменений, из-за которой код, написанный под 3-ю версия пришлось переделывать. Основные изменений коснулось части конфигурирования фреймворка. Не мало параметров либо удалили, либо перенесли на други уровни, либо переделали полностью. Совсем не порадовали ограничения введенные в 4 версии особенно всего 10 запросов. Однако из-за открытости кода — эти вещи можно самому поправить :) Только вот о лицензионной чистоте уже можно будет забыть.