Озверин1. В версии http 1.0 каждый запрос порождал соединение. Запрос - соединение создается - ответ - соединение закрывается
1.2. Один запрос - один поток. Причем это дорогой поток, потому что является блокироующим: и поток, и ресурсы(база, файл, io).

Тут кроется проблема - скорость! http 1. 0 медленный из-за того, что на каждый запрос приходится открывать и закрывать соединение

2. В версии http 1.1 в рамках одного соединения может быть несколько запросов, каждый из которых будет в своем отдельном потоке.
Скорость увеличивается для клиентов, которые посылают запросы пачками, но, возникает проблема, что web container быстро расходует pool потоков."Смешались в кучу кони, люди ..."
Постоянные подключения появились уже в HTTP/1.0 (прагма keep-alive). HTTP/1.1 сделал постоянные подключения вариантом по умолчанию (Connection: close). Детали когда "можно постоянные подключения" - опускаются.
Постоянные подключения сами по себе не увеличивают число потоков исполнения - запросы продолжают поступать и обрабатываться строго последовательно.
Установление подключения - десятки-сотни миллисекунд и для запросов продолжительнее трёх-пяти секунд это не очень существенно. При некоторых оговорках, которые могут и не выполняться.
Поток не может быть "дорогим" - если для исполнения требуются определённые ресурсы, то придётся их потратить в любом случае.

Семантика асинхронного контекста сервлетов 3.0 позволяет контейнеру оптимизировать управление ресурсами. Реализованы эти оптимизации в конкретном контейнере и возможно ли их задействовать в конкретном сценарии - вопрос отдельный.

Асинхронный ввод-вывод в сервлетах 3.1 позволяет задействовать (и достаточно просто) оптимизации ввода-вывода не только на уровне контейнера, но и в прикладном коде. Будет с этого какой-то выигрыш - вопрос, опять-таки, отдельный.