Should you cap the framerate: Yes
Is a high CPU usage unwanted: Yes
Or even dangerous!: Could be but if so not your problem
You want to cap the framerate because you are extremely unlikely to achieve any benefit (to your game) by calculating at a frequency higher than your ability to display the results. ie, if your monitor can only display at 60Hz then displaying at 200Hz achieves nothing because the display will a) ignore frames and only display at 60Hz anyway or b) display ugly tearing.
The high CPU usage is unwanted because you are drawing unnecessary current from the CPU and from the GPU, raising the temperature, fan speeds and your unsuspecting customers power bill :-)
Running at 100% CPU usage across all CPU's and flatlining the GPU simultaneously may possibly cause some system to overheat and even fail, but that would only be because that system is misconfigured (or improperly overclocked). So such a system failure would primarily be caused by the configuration error, you just triggered it. If you follow the above two guidelines this becomes a moot point.
Related to this is the internal logic & movement system which while not strictly tied to the framerate in theory, in practice it often is. The human eye very sensitive to tiny fractions of a second difference, particularly where it relates to input and game response to the input. So it's a really good idea to check player input only immediately before updating game characters, and also to put that part of the code as late in the game loop as is feasible.
The trick is doing all this as close as possible to your frame time slot without going over and missing your refresh.
For example at 60Hz you have 16ms per frame, and if your main loop takes 6ms, it's better to execute it at the 9ms mark rather than at the 0ms mark and lagging by 10ms.
Executing it as late as possible with a tiny leeway will make it feel just that touch more responsive, and gamers will notice.
Keep your loop timing tied to the vsync signal rather than some arbitrary random game start time. Also keep in mind that high res timers will derive over time so you'll need to watch it to keep it in sync. This way your 6ms main loop won't accidentally finish a millisecond after the screen refreshes so that you have a whole 15ms lag.
If you think it's ridiculous to say that a player would notice such a small interval, then go read this 2006 study to see just how quick the human eye is (this article includes a cognitive response to a massive amount of visual data in it's timing).
Also note player comments where they are adamant about noticing game responsiveness when the refresh rate is in fact beyond the ability of their monitors to display it.
It is because the very freshest data was used when drawing the frame they do see.
Also be careful as vsync synchronisation can make your program 'freeze' for a few ms while waiting for vblank. There is an excellent discussion of the vsync issues over at virtualdub.org as well as one at opengl.org on swap interval (now archived at the Wayback Machine) (read the talk page on opengl.org as well)
