"..modern CPUs are cheap and will degrade quickly at 100% CPU".
You don't have to worry about "CPU degradation" at all. Modern CPUs are not of less quality than in former times.
It is very expensive (and is getting more expensive every couple of years) to make CPUs, some billions to build a new fab are not uncommon (see link).
The production costs of a CPU depends at most on the no. of units produced. This is a well known fact in economy. That's the reason they can be sold (relatively) "cheap" after all.
(I think, no link necessary here)
I can list a number of reasons why I would consider modern CPUs to tend to be of more quality than in "former times".
But only the most important: Advantages in testing. Modern electronics are "designed for test". Whether software or hardware, the broad insight of valuing tests over nearly everything else, is not so old.
For CPUs, the tests are even taken for forming the different price and frequency types, e.g. the best CPUs are sold with highest frequencies. Despite that, the cheaper processors are very often able to operate with higher frequency than sold- they are crippled only for the reason that the manufacturer wants to sell some "high level" processors with higher prices.
(One the other hand, of course there are more errors possible for a processor with more than 1.5 billion transistors as normal nowadays than with some thousand transistors of a processor of the seventies. But this does not contradict to my answer IMO. Processors in general tend to have many known errors, at least in microcode, but this is not subject here.)
There are even more reasons not to worry about CPU degredation for your program:
First reason is that modern CPUs decrease their frequency or throttle, if they are getting too hot.
It should be clear that if you utilize the CPU 100% 24/7 the whole year it will normally die earlier than a CPU only used every second week one hour. But that is true for cars, too, by the way. Only in such cases I would think about CPU utilization and potential sleeps yourself.
Second reason is that it is really very hard to write a program which uses 100% of the CPU from OS, (e.g. in Windows). Besides, modern CPUs (normally) have at least 2-4 cores. So a traditional algorithm which tends to use 100% of a single core CPU, now has only 50% on a dual core CPU (simplified but seen in real scenarios).
Moreover the operating system has the control over the CPU and not your program, so if there are other applications with same or higher priority (what is the default), your program is only getting as much CPU as possible, but the other applications will not starve. (Of course this is only the simplified theory, and of course the multitasking of Windows, Linux and others is not perfect, but overall I would consider that for true).
"I was previously under the impression that 100% CPU usage was
preferable for an intensive or long operation.."
Yes, stay with this. But for example, if you do waiting&looping for another process, in other words doing nothing, it would be not too bad if you Thread.Sleep() some milliseconds in that loop, giving extra time to others.
Whereas it is not necessary for a good multitasking OS, I solved some issues with this e.g. for Windows 2000. (That does NOT mean of course to use Sleep() in calculations for example..