> Во-первых, первым слетел бы тот, кого убил бы OOM.

Так весь пойнт в том чтобы поставить столько памяти, что OOM случается только при runaway и не случается при нормальной эксплуатации вообще совсем. Грубо говоря если у тебя 4 гига памяти и 4 гига свопа - с точки зрения приятности эксплуатации системы намного лучше будет поставить 8 гигз памяти и никакогош свопа. При этом будут доступны те же 8 гигз, только последние 4 гига не будут добиваться с истошным тормозиловом и клином всего что угораздило выпасть в своп. Мало 8? Ок, поставим 16. Все-равно ты с практической точки зрения опупеешь от времени (пере)записи и чтения свопа крупнее 1-2 гигов. Я как-то совсем не готов десятками минут ждать пока система протормозится.

> с кучей страниц или IDE  с большим проектом. Моё предположение
> - что система не угадывает, что можно вытеснить в своп

Искусственный интеллект, который заранее знает что приспичит пользователю - еще не изобрели. Поэтому естественно в своп будет улетать как dead code и такие же данные, так и то что потом через полдня юзеру понадобится (но система про это ессно не знала).

> файловых буферов, причем в основном - которые на чтение).

Как по мне - так идея выиграть дисковый буфер для ускорения I/O за счет тормозов от свопления - очень спорная идея, мягко говоря.