Да, вот это интересно :-)

Правда, это уничтожает идею выполнять app-серверы отдельно, а не внутри web-сервера, а она имеет свой резон: web-сервер, занимающийся передачей данных от юзера и обратно совершенно не нужен во время выполнения app-сервера, обрабатывающего эти данные. Если запихать их в один процесс, то одна из его частей всегда будет простаивать: Django будет сидеть и ждать, пока передаются данные, а nginx будет сидеть и ждать, пока они обрабатываются.

С другой стороны, это совсем плохо только с многопроцессной архитектурой. А с асинхронным nginx’ом это может и не быть особенной проблемой.

От lighttpd дождаться симметричного ответа не получится. Поскольку lighttpd - это state machine, то любые длительные действия будут тормозить весь сервер, так что без внешних процессов и FastCGI/SCGI/AJP/какого-нибудь-ещё протоколов уйти нельзя.

У nginx есть пул рабочих процессов, каждый из которых можно тормозить на сколь угодно продолжительный промежуток времени (пока есть хотя бы один свободный - сервер будет работать), а lighttpd - это один процесс, внутри которого задачи и диспетчеризуются. Такая архитектура позволяет снизить overhead на переключение между процессами операционной системы, но при этом предъявляет требования к самим задачам: их нужно уметь делить на мелкие кусочки и ожидать.

Отдача статических файлов или перекачка данных из внешнего CGI/FastCGI-приложения - как раз такие подходящие задачи: их можно ждать на poll/epoll, и они естественным образом делятся на кусочки - сколько данных приехало, столько и записали в сокет.

python-интерпретатор - дело совершенно другое, его в произвольный момент времени остановить нельзя.