"Surprisingly, these benchmarks seldom exceed 50% load on any of the ten cores, which raises the question of how accurately they represent maximum CPU performance." Eh, maybe. I'm not inclined to rely on the reported % CPU usage to represent anything useful. For example, it's very easy to be at 100% CPU when you're actually spending most of that time waiting for memory reads.
CPU % is such a complex metric that it hardly means anything real other than an general feel for how busy the system is. I have seen on linux that I can be running something that uses 100% and the cpu is at 50c, then I run prime95 also at 100% and the cpu instantly hits 99c
It's a simple metric, but it can be complicated to relate it to what is going on with execution because the real system is very complicated.
The CPU % metric does not take into account execution strength, of the CPU, big vs small, dynamic CPU frequency, or effect that one CPU might have on another (e.g., SMT or shared caches or memory controllers).
Further complicating it is that the Linux CPU scheduler is not work-conserving. So you could have at least 100 application threads runnable at any given moment in your workload, but your 64 CPU system might only be hitting 80% CPU busy.
Then you get to application and kernel effects of course, locking, blocking, etc. can mean you don't even have as many runnable threads as you might think.
Then how all this actually relates to the work and heat the system creates is another matter again. Simple integer execution might only use half the CPU power of a vector heavy workload because you have fewer transistors clocked or switching (or even powered) in the core.