IMHO use all the CPU you can, and more than likely you will unless you want alot of overhead slowing the program down. I wouldn't worry CPU usage and worry more about RAM usage.

I'd offer the advice of accepting the "WM_FOCUS" message, so that you know when your program is in focus.
While they are looking at your game, who cares if it hogs all the cpu. But if they have to alt-tab away from
it, you should play nice and pause your game loop. (or give an option to, kinda how TheSims has the option
"sims in background" to toggle if it pauses on alt-tab or not)

I had the exact same problem, and I posted the same thread "What loop do commercial apps use, so the CPU won't jump to 100. I was using D3D, I don't know if you are, but Ill try to help anyways. What I noticed is that when I started the game and the window opened the CPU shot up to 100, but then if I resized the window, CPU would drop to about 20% and stay there.
Just in case heres my thread, its pretty long since there was an argument that games are supposed to use 100.
http://www.gamedev.net/community/forums/topic.asp?topic_id=433940

At the end what I realized is that it was the two calls to antialiase that seemed to be slowing everything down, I removed them and everything ran fine at 20-30% CPU.

"Sleep loops" aren't automatically unreliable. If it is just a naive sleep loop, attempting to rely on Sleep() to actually time each iteration of the loop, then yes, it will work out badly in many cases. However, there are some loops that work very well at 100%, but it is also very easy to add in a Sleep() call into the loop, and the loop will still work perfectly well, while CPU usage is greatly reduced (depending on the CPU intensity of the game, of course). This is because the loop uses other techniques to manage timing and such, but still sleeps to be nice to the system. The key is to make the loop inherently compensate for iterations that take less or more time than is intended.

If an iteration took too long, then the following iterations need to be done more quickly until it is caught up to where it should be. In many cases, this involves running game-logic stuff at full speed as many times as necessary to catch up, without rendering at all. If the previous iteration lasted as long as 3 iterations should last, then the next time through, run the game-logic three times (such as managing game objects, running physics, et cetera), and only render after that point. If rendering is the problem, then the game will continue running internally at the same speed, but your framerate will be lower.

If an iteration went by too quickly, well then that just means that you can sleep longer. If you still didn't sleep long enough, then just skip everything else for that time, and sleep again. You can render if you want, or perhaps handle input, in order to maintain a high feel of responsiveness, but it likely doesn't need to be done for many games.

If you get your loop done well, then you can have each component of your game running at a potentially different frequency, as well as each component choosing if it can skip missed iterations if it likes. To get repeatable reliable physics, then have it run at a fixed frequency of 45 Hz, for example, and not allow skipped iterations. Run input at 120 Hz for quicker response, perhaps, but allow it to skip iterations. If you missed a few iterations due to a hiccup, there's no reason to check input three times in a row as quickly as possible; just check it once. Allow an option to let graphics run at the same frequency as input, as fast as possible, or at the vertical retrace frequency. Again, don't bother rendering frames that were missed, there's no use. If there's networking, perhaps let it run at yet another frequency. If you get things set up well, you might manage to obtain a good number of the benefits of multithreading while still using a single threaded model.