«Dividir em mais threads um problema cpu bound[...]»
Esse que é o problema, eu não disse isso em lugar nenhum. Nem disse que melhora nem que piora a performance. Quando eu falo de "dividir o trabalho" eu me refiro a execução do software no geral, não de um algoritmo.
Troca de contexto nem sempre é ruim, é importante dar espaço para outros processos senão o escalonador vai prejudicar a performance do seu software. É por isso que softwares que consomem CPU em excesso começam a travar — é o kernel fazendo isso.
Além disso, você também não quer prejudicar a execução de outros processos a menos que o software execute em um contexto em que isso faça sentido.
Sobre exemplos: O simples fato do GNU make ter a opção -j já serve muito bem para exemplificar o que eu estou dizendo. E também provar na prática que o uso de threads assim realmente acarreta em ganho de performance. Faça o teste: Compile um projeto com e sem -j e veja em qual dos dois casos termina mais rápido.
Você pode ver outros softwares com opções semelhantes, como o -threads do ffmpeg.
E antes que diga o que eu estou prevendo que dirá, repito: «Dividir em mais threads um problema cpu bound[...]» não foi o que eu disse. Então não responda dizendo que nem o make nem o ffmpeg fazem isso. Realmente não fazem.
Mas do outro lado da moeda existem pessoas que acreditam que usar mais threads é "mais lento" dando a explicação de que você basicamente está dividindo a mesma capacidade de CPU para duas threads.
Começou o texto afirmando isso e terminou com aquilo. Mas claro deve ser só eu que não sei interpreter texto que viajei achando que estava falando de um problema cpu bound quando apenas estava se referindo a capacidade de processamento da cpu como a execução do software no geral e não de trabalho real da cpu, my bad.
Claro se a cpu ta ociosa usar mais threads é um jeito muito eficaz de ocupar ela. Mas não foi isso que entendi do seu texto.
Enfim um abraço e bons estudos muchacho.