A principal razão por trás disso é que o usual: E / S é muito mais lento que CPU / RAM. Mesmo se os processos que executam operações de E / S usarem o DMA (que descarrega a CPU), em algum momento provavelmente precisarão aguardar a conclusão de suas solicitações.
No caso mais comum de um disco rígido, basta adicionar vários aplicativos que tentam acessar os arquivos espalhados pela unidade, e você pode fazer um café (chá, qualquer coisa). Com SSDs, a situação melhora, mas até mesmo um SSD - que tem um throughput medido em centenas de MB / s em SATA (comparado a dezenas de MB / s de um HDD spin-plate) e tempos de busca realmente insignificantes (comparado a milissegundos para um spin-plate) - pode se tornar um gargalo.
O problema que eu entendo não é apenas nas próprias transferências de dados, mas na sobrecarga necessária - a E / S é controlada pelo kernel, mas raramente acontece sem o espaço do usuário. Assim, pode haver vários switches de contexto, apenas a partir dos aplicativos que estão aguardando a E / S, verificando se algo está acontecendo (depende da implementação, é claro). No caso de transferências de disco, pode haver vários encadeamentos do kernel competindo por recursos ou esperando ocupado (o que às vezes é uma estratégia apropriada). Lembre-se, por exemplo, copiar dados de uma partição para outra exige um sistema de arquivos moderno para: descobrir onde os dados de origem estão, ler, alocar espaço no sistema de arquivos de destino, gravar metadados, gravar dados, repetir até terminar.
E se, em algum momento, o sistema iniciar a troca (que geralmente tem prioridade mais alta que a E / S normal), o desastre será finalizado.
EDIT : Depois de conversar com alguns desenvolvedores do kernel Linux, a situação ficou um pouco mais clara. O principal problema é o escalonador de E / S, que não tem muita ideia sobre qual E / S priorizar. Portanto, qualquer entrada do usuário e saída gráfica a seguir está compartilhando a fila com a atividade de disco / rede. Como conseqüência disso, também pode acontecer que ele elimine dados do processo armazenados em cache do cache de páginas (por exemplo, bibliotecas carregadas) quando conclui que pode usar o cache de páginas com mais eficiência em outras E / S. Isso significa que, uma vez que o código precise ser executado novamente, ele terá que ser buscado novamente - forma o disco que pode estar sob carga pesada já.
Dito isso, no que diz respeito ao kernel do Linux, muitos desses problemas foram corrigidos recentemente (o problema é conhecido), então diga 4.4.x ou 4.5.x deve comportar-se melhor que ele costumava e problemas deveriam ser relatados (geralmente as pessoas do kernel ficam felizes quando alguém quer ajudar com relatórios e testes de bugs).