> пусть медленно, но чтоб оно пережевалось корректно, а не дропнуло половину
> процессов оом киллeром,

Пардон, а ничего что oom killer вызывается ядром ОС? Программа в общем виде ничего с этим сделать не может: если ядро решит что программа свое отлетала, оспорить это программа может только в спортлото. Более того - в общем случае программа не может даже знать сколько памяти ей дадут. А с оверкоммитом и вовсе все весело. Но о таких мелочах бидонисты не знают - им надо чтобы за них подумал ЯП и рантайм, а своего мозга у них обычно нет.

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

Нормальные люди давно в курсе что такое "машина состояний" (FSM) и просто не имеют таких проблем. Для того чтобы что-то делать в 1000 соединений достаточно 1 процесса. И даже 1 потока. Ну может несколько, e.g. по числу процессоров, если нагрузки совсем уж дофига.

> и грузила ими обозначенное кол-во исполнителей, сосбтвенно и апач, и нжинкс,
> и пхп-фпм и др, так и работают,

Нжинкс - как раз таки машина сотояний. Поэтому и может даже в 1 процесс и поток держать тысячи соединений, с весьма умеренным потреблением ресурса, в отличие от опача, который по процессу на запрос плодит в дефолтном виде. И именно поэтому у него есть немного своих заморочек по части блокирующих операций.

> только скрипт туда не подвязать,

Для FSM критерий прост: в FSM нельзя надолго вставать колом, так что операции вызывающие длительное блокирование потока (команд, треда) - FSM не друг.

> вот отсюда ноги и растут, вот и приходится выбирать между костылями.

А у питонистов судьба такая :)