"..as CPUs modernas são baratas e degradam-se rapidamente a 100% da CPU".
Você não precisa se preocupar com "degradação da CPU". As CPUs modernas não têm menos qualidade do que antigamente.
É muito caro (e está ficando mais caro a cada dois anos) fazer CPUs, alguns bilhões para construir uma nova fábrica não são incomuns (veja o link).
http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant
Os custos de produção de uma CPU dependem no máximo de não. de unidades produzidas. Este é um fato bem conhecido na economia. Essa é a razão pela qual eles podem ser vendidos (relativamente) "baratos" depois de tudo. (Eu acho que nenhum link é necessário aqui)
Posso listar uma série de razões pelas quais consideraria as CPUs modernas tendem a ter mais qualidade do que nos "tempos antigos".
Mas apenas o mais importante: vantagens em testar. Os eletrônicos modernos são "projetados para teste". Seja software ou hardware, o amplo insight de avaliar testes em quase todo o resto não é tão antigo. Para CPUs, os testes são feitos para formar os diferentes tipos de preço e frequência, por exemplo, os melhores CPUs são vendidos com as frequências mais altas. Apesar disso, os processadores mais baratos costumam operar com maior frequência do que os vendidos - eles são prejudicados apenas pelo motivo em que o fabricante deseja vender alguns processadores de "alto nível" a preços mais altos.
(Por outro lado, é claro que existem mais erros possíveis para um processador com mais de 1,5 bilhão de transistores normalmente hoje em dia do que com alguns milhares de transistores de um processador dos anos setenta. Mas isso não contradiz a minha resposta IMO. Processadores em geral tendem a ter muitos erros conhecidos, pelo menos no microcódigo, mas isso não está sujeito aqui.)
Há ainda mais motivos para não se preocupar com a degradação da CPU do seu programa:
A primeira razão é que as CPUs modernas diminuem a frequência ou o acelerador, se estiverem ficando muito quentes.
Deve ficar claro que, se você utilizar a CPU 100% 24 horas por dia, 7 dias por semana, durante todo o ano, ela normalmente morrerá mais cedo do que uma CPU usada apenas a cada segunda semana uma hora. Mas isso também é verdade para os carros. Somente nesses casos, eu pensaria na utilização da CPU e no potencial que você dorme.
A segunda razão é que é realmente muito difícil escrever um programa que use 100% da CPU do sistema operacional (por exemplo, no Windows). Além disso, as CPUs modernas (normalmente) têm pelo menos 2-4 núcleos. Portanto, um algoritmo tradicional que tende a usar 100% de uma CPU de núcleo único, agora possui apenas 50% em uma CPU de núcleo duplo (simplificado, mas visto em cenários reais).
Além disso, o sistema operacional tem o controle sobre a CPU e não o seu programa; portanto, se houver outros aplicativos com a mesma ou maior prioridade (qual é o padrão), seu programa estará obtendo o máximo de CPU possível, mas os outros aplicativos não morrer de fome. (Claro que essa é apenas a teoria simplificada e, é claro, a multitarefa do Windows, Linux e outras não é perfeita, mas no geral eu consideraria isso como verdade).
"Eu estava anteriormente com a impressão de que o uso de 100% da CPU era preferível para uma operação intensiva ou longa .."
Sim, fique com isso. Mas, por exemplo, se você espera e faz um loop por outro processo, ou seja, não faz nada, não seria tão ruim se você Thread.Sleep () alguns milissegundos nesse loop, dando tempo extra a outros. Considerando que não é necessário para um bom sistema operacional multitarefa, resolvi alguns problemas com isso, por exemplo, para o Windows 2000. (Isso NÃO significa, é claro, usar Sleep () em cálculos, por exemplo.