Is changing the priority of a game's process to realtime bad for the CPU?
Changing the priority of a process only determines how often this process will run when other processes are competing for CPU time. It has no impact when the process is the only one using CPU time. A minimum-priority process on an otherwise idle system gets 100% CPU time, same as a maximum-priority process.
So you can run your game with a higher priority, but that won't make it run faster unless something else on the system is using a significant amount of CPU time.
I recommend keeping the priority lower than the X server, because if the X server wants CPU time, it's likely to be because the game is asking it to display something complex, and display is usually a CPU-demanding task (but it depends how much of the work is done in the GPU — CPU priorities have no influence on the GPU).
CPUs are designed to execute code. Changing process priorities won't affect how much work the CPU does, but even if it did, that wouldn't damage the CPU, it would only make it run hotter and so make the fans in the computer blow harder.
Are you talking about altering the amount of CPU demand while it's running the thread?
Modern CPU's actually use extremely rapid speed stepping. For example if you did analysis of the clocking of an Intel Core i5/i7 you can see the the clock speeds flickering up and down really really quickly. It's part of the way that Intel can tune the performance relative to amount of power drawn. You might have loads of power available in a desktop PC but the stuff is being converted to heat when the CPU is working harder, so it's important to get the most bang per watt.
I only know this from what I have read on other gaming forums. I'm not a CPU scientist.
I don't think you'd do any damage from tuning a thread to it's maximum "nastyness". The only thing you should keep an eye on is how hot your CPU is getting, but unless you have used overvolting in the BIOS then it's pretty impossible to cook the CPU before it shuts down.
Modern CPU's are designed to rapidly change speed. Do a search for Intel Speed Stepping and 'CPU C states' and you'll see what I mean.
Using renice on a Linux program will not burn up your CPU, but it will not necessarily do what you want it to do.
Priorities have nothing to do with how fast a CPU executes code. It executes code from programs in different priority levels equally fast. What priorities do change is which program the operating system chooses to run when given a choice. CPUs can only run one "thread" of execution at a time (technically 1 per core for multi-core CPUs). If it needs to do more than that, it relies on multitasking - it switches back and forth between executing different programs to give the illusion of running more threads than there are CPUs. When choosing how much time to give to each of these tasks, it does so using the priority as a hint.
What "realtime" means to a computer is less "run this fast" and more "do not preempt this process." Realtime programming is very important in many fields. For example, if I was writing software which manages anti-lock brakes in a car, I really don't want my task to run a few milliseconds late because the OS decided it needed to run a diagnostic on the windshield wipers. Accordingly, the anti-lock brake management software in cars is run at a "real time" priority.
Truthfully, in Linux, the "real time" priority level is a bit of a misnomer. This is because of how Linux schedules its processes. In windows, if you have a process that is running at a higher priority, the processes running at lower priorities are given no CPU time unless the higher priority task is waiting for something -- none at all. Only kernel processes are permitted to run over the top of a "realtime" Windows task. Windows has a ton of bloatware running in the background at all times, so raising the priority to "realtime" prevents all of that junk from running.
However, there's an issue with this. Sometimes your higher priority task is dependent on one of those lower priority tasks. This is called "priority inversion" and it is a big topic in the world of multithreaded programming. When this happens, the higher priority task can starve the lower priority task, not realizing that it is stopping itself! In Linux, this doesn't happen because in Linux, the priorities are viewed as a way to determine what portion of the CPU is given to each program, rather than an all-or-nothing approach. A process running at -20 gets substantially more CPU time than one running at 0, but even in the presence of a -20 program, the 0 program gets some CPU time. If memory serves, the current Linux scheduler gives a program at -1 twice as much CPU power as a 0, and a program at -2 twice as much as a -1, and so forth. This means that 0.9999046% of your CPU time will go to the program that's at -20, but some small fraction does go to the program at 0. The program at 0 will feel like it's running on a 200kHz processor!
If you ever want true real time, where you can prevent anything else from preempting you, you have to write a kernel driver, or you have to use a real-time extension to Linux. Redhat has one called MRG, which permits true real time processing with Linux. In that case "realtime" means something speicific. Under MRG, users in the "realtime" group are permitted to use these real time extensions (which could keep the processor busy forever, because they're intentionally not using the nice friendly Linux scheduler).