Sorry for the late reply, I haven't been back here in a while. I still play OA and Quake III just the same, though.
Because that's Q3A's default, and for a long time the physics were dependent on this FPS value, and it'd make less sense to change that default to 60 anyway (compatibility in mind). Even if your panel doesn't see all frames beyond 60 there is still a difference input response-wise. Mine doesn't either, it's why i'm trying to code in
motionblur to blend in frames that I can't see
OA shouldn't overheat that much really, it's more of a CPU choker because of the model transform processing all those verts all in a single thread, and a relatively more potential GPU fillrate choker from the detail textures. r_lodbias 2 and r_detailtextures 0 should turn things down to a more relative 'q3 look' . Another CPU choke is the detail textures enabling the specular stage of player model skins and weapons, which require additional light reflection calculations for it to shine.
r_flares is also heavy in 0.8.8 because it is an expensive readpixel process (it's always slow to read from video memory). The latest engine on git adds r_flarequality which can change the method to a faster but less accurate one (and makes a big difference in fps on some maps, like pvomit)
A Pentium M laptop should handle OA even at its battery-saving speed (around 500mhz IIRC)
That's interesting how much is being done on the CPU, and that's one reason I have the flares turned off. (I don't turn down model or texture quality, since I like pretty games, but I can make a few sacrifices with lighting for FPS if I have to.) This is an older engine we're talking about here, so that's expected, and if you're using an Intel GPU, like me, the CPU's stuck sharing some of the load on modern games anyway. *bricked*
A few more things related with CPU usage.
IIRC, the game is single thread, so it uses a single core of the machine it any case (oh well, one may use a process as a dedicated server, and then connect to it from another process as client from the same machine....)
IIRC, in the original Q3, also setting a lower com_fps value did not help saving the CPU, because the "wait" cycle it used always consumed all available CPU time. ioquake3 did change this behavior, so in ioquake3 (and in OA) you can actually save your CPU usage by setting lower FPS. It's however possible to set the old behavior.
About framerate, its default is 85 (actually 90) because that was the original value of Q3.
Most maps were designed with either 90 fps (default value) or 125 fps (usually set by "pro" players, due to giving some adavantage with framerate-dependent physics -at default 800 gravity-) in mind. I don't know if 60 fps gives the same good effects of 125 fps... However, nowadays one can use "accurate" physics in OA, where the jumps should be fair and should be something in-between the 90fps and 125 fps physics.
So the physics are indeed frame-dependent? And I didn't know the wait cycle behavior was improved with ioquake3. One of many reasons for me to keep playing Quake III with OpenArena instead of the original engine, wow.
When I have a desktop computer, and maybe a monitor with a higher refresh rate, I'd like to turn it back up to 85-90. The AI will probably beat me to a pulp again, though, they're a lot faster and smarter at that rate too.
Would defrag be better at 90, though? I get the feeling wall climbing with the Plasma gun is basically impossible at 60; I can only go so high before falling back down.
60 FPS feels pretty good in the meantime. It's still fast and doesn't tear as often.