Arm79SeVaТам, где высокие нагрузки ORM не используют, а в ADO.net это уже есть.
+1 с примечанием: я использую BLToolkit, тк по быстродействию уступает нативному коду на пару процентов, не более, зато гораздо удобнее в использовании. Entity Framework или NHibernate на порядок, если не больше, медленнее.

SeVaЗЫЫ Должен использоваться PerCall, для которого создается новый, отдельный инстанс
+1, при условии что у автора WCF. Просто бесконтрольные таски/потоки при большом количестве коннектов сами сожрут кучу ресурсов. WCF поволяет регулировать количество таких потоков.

Когда-то я делал сервис PerSession с моделью подписки и запоминал коллбэки клиентов. Несколько тысяч клиентов держало на раз. Как раз было ожидание ответа со стороны внешних ресурсов.

ИМХО: если ожидания нет, а идут интенсивные расчеты (хотя я пугаюсь от таких расчетов, идущих по 5-10 секунд), то только PerCall.

SeVaновый API с asyn\await, которые НЕ СОЗДАЮТ НИКАКИХ ФОНОВЫХ ПОТОКОВ. Для вызовов БД это можно сделать.
Не работал, не знаю, но мне кажется, что полноценно без фоновых потоков асинхронность не сделать. Я читал вашу эмоциональную дискуссию в другом треде, но не уверен, что вы правы на 100%. Куча примеров с MSDN используют async/await совместно с Task и методами *Async. А для БД я сам делал асинхронное обращение к базе и выдачу результата по коллбэку. Все работало очень шустро.

Если работало шустро, то значит не было задержек. Для подобных задач пулы работают нормально, поставь задержку в сервисе хотя бы секунду, сразу получишь десять на выходе от первой сотни одновременных вызовов.
Если кажется и не можешь понять, что пишут черных по белому, а лучше всего проверить, да посмотреть в профайлере, то остается только креститься