cdtyjvУ меня вопрос: что не так с .Net?
Не так с .NET то, то он создан для решения реальных задач, а не для дебильных микробенчмарков.

Например почти все примеры из репозитария отдают ответ без буферизации, а .NET буферизирует. Буферизирует ответ для того, чтобы можно было парой строк включить HTTP-кеш, который работает как на клиенте, так и на сервере.

А в говноподелках на куче всяких ферймворков прикрутить клиент-серверный кеш с валидацией и conditional get - надо будет тонну кода написать и он будет тормозить неслабо.

В реальных задачах HTTP-кеширование - основной инструмент для повышения быстродействия сайта.
Вот примеры:
http://habrahabr.ru/post/168869/
http://habrahabr.ru/post/227129/
Если лень читать - взял банальный MvcMusicStore и прикручиванием кеша разогнал его в 5 раз. При этом пришлось в совокупности поправить 15 строк кода. И это я не трогал ни запросы, ни пытался что-либо оптимизировать в коде приложения.

Кстати если буферизацию выключить, то вариант с C++, nodejs и Self-Hosted WebApi дали почти одинаковый результат на локальной машине.

cdtyjvПочему никто не может написать на нем нормальный высокопроизводительный сервер? Кривые руки разработчиков ASP.NET? Кривая платформа? Или просто напросто никто не пишет высокопроихводительный софт на .Net (читай - это никому не нужно)?
А с чего ты взял что никто не пишет или не может? На основании микробенчмарков? У меня был сервер который держал 150 клиентов и стримал данные с датчиков во 80 пактов в секунду. Пакеты были около 1к+оверхед от .net.tcp. При этом он насыщал 100мб сеть, кушая не более 20% одного ядра и 100мб памяти.

Я не стал изобретать всякие велосипеды с кастомной сериализацией и прочей муйней, а просто поправил код, чтобы он отправлял только измененные данные и нагрузка сети упала до 10%.

В практических задачах кешироване рулит в разы сильнее, чем скорость вообще любого компонента в отдельности.