>> Вы же сами смешали операции распаковки (распараллеливание в частных случаях возможно и
>> даёт выигрыш) и записи (где при возможности асинхронного ввода-вывода создание потоков
>> на каждый чих выглядит лишней операцией).
> Файловые операции занимают самую минимальную часть времени на системах с SSD, тем
> более высокоскоростных SSD.

По-вашему выходит, что нет смысла оптимизировать файловые операции (напомню, изначально речь шла о ядре, где они и выполняются).

> Даже при загрузке linux системы более половины всего
> времени дисковой накопитель простаивает, и это на топовом современном железе.

На самом деле скорости линейного и произвольного чтения различаются, именно их Вы и сравниваете словом "простаивает". Производительность процессора заметного влияния не оказывает (на несжатых на уровне ФС данных).

> Например, загрузка из сети десяти deb пакетов распараллеливается

Скорость загрузки ограничена шириной канала. Вы удивитесь, но на транспортном уровне "пакет" относится не к deb, а tcp. Соответственно нет существенной разницы, сколько файлов одновременно передаётся.

> но их распаковка все
> равно идет друг за другом, а не параллельно, хотя никаких ограничений
> к этому нет (в разумных пределах конечно же, пока не упремся
> в дисковый накопитель и свободное место на нём).

Распаковка выполняется не в ядре. Если алгоритм и реализация поддерживает многопоточность, значит надо при вызове функции (или утилиты) распаковки их использовать.

> Конечно же, это гораздо быстрее чем отвратительная система обновлений win10, где вся
> система ложится на период обновлений, но тем не менее проблема однопоточности
> есть.