I elided a lot detail for the sake of making a simple example about power consumption.
For applications that don't need hard real-time and/or aren't very high frequency, one could set the CPU frequency governor to always run at max frequency. You're right in that this can be done at runtime without a need to disable CONFIG_CPU_FREQ.
To achieve hard real-time at high frequency (roughly >10kHz), the standard kernel and PREEMPT_RT are not sufficient. One approach is to use a microkernel that preempts the Linux kernel. RTAI and Xenomai are two frameworks that do this. Processes run through them cannot be preempted by the kernel, so deterministic timings can be much better guaranteed. It's in this case that one would disable CPU scaling (along with Intel pstates, ACPI power management, and other things I don't remember offhand) when compiling the kernel. Changes in CPU frequency can change the frequency of the time counters on the CPU, and that opens up a vector for the vanilla kernel to interfere with the timers used by the microkernel and potentially break real-time.
Now, is it true in this latter scenario that one, as I said, "needs to" disable CPU scaling entirely? Now that you've got me thinking about it, probably not. If one guarantees that the 'performance' (i.e. max freq) governor is running at boot, leaving CONFIG_CPU_FREQ enabled may be fine. (The default governor will still need to be changed to the performance one in the kernel config, though.) Setting max frequency at runtime, however, maybe not. This is probably an edge case (I haven't tested this), but if the system boots with a dynamic CPU frequency enabled, the standard kernel, which cannot access information about threads controlled by the microkernel, could scale down the CPU a real-time thread is running on and mess up the timings. Changing the frequency mode at runtime after that happens may not fix that issue.
If I were to write that again, I'd use "should" or instead of "needs to." It's much simpler to disable frequency scaling in the menuconfig while disabling everything else than it is to leave it in and worry about it afterward.
None of this changes the point about real-time and power consumption, though.
The degree to which the OS deviates from the vanilla kernel behavior depends on the requirements of the processes being run in real-time.
For example, to run hard real-time, high frequency (>10 kHz) tasks with low latency and jitter, one needs to disable CPU frequency scaling (among other things) when compiling the kernel. The result is higher power consumption.
I hadn't thought of the Damore fiasco in a while. I'm not particularly pleased to revisit it. To me, it was a strong indicator to those in industry that a good-faith attempt at discussion on potentially controversial topics can blow up _badly_. One is better off to keep silent and not stick one's neck out. Since then, I've seen worrying trends in academia that suggest it will follow suit...
In the years since 2017, there has been a strong push for scientists to take upon themselves the responsibility for not just conducting research but also for the way the public discussion unfolds. To so do, they collaborate to create uniform messaging so that bad actors cannot find disagreements over details and implications and use them to sow divisions among the general public or, at worst, inflict harm on populations deemed vulnerable.
This creates problems in that scientists are pressured to be silent with their own disagreements. (e.g. One should not value one's individuality over solidarity.) This is particularly acute if one is in the minority of opinion. My concern is that over time, this pressure will diminish variance in opinion on any given topic. Variance will become invariance, and that invariance will then be misinterpreted as proof of Truth. Any research or even opinion at odds with it become outrageous.
As this unfolds, more and more people will fall into the same trap as the author --- dismissing unpalatable albeit tendentiously backed arguments as unscientific and reflective of deep, un-measurable cultural evils while accepting extrapolations from similarly tendentious research that backs a more acceptable narrative, e.g. "because the authors of the paper are women, ... we can expect 10 percent fewer citations."
I find all of this deeply dispiriting. The capacity for science to produce models that reflect the natural world depends on the free dissemination and interrogation of all ideas. Though John Stuart Mill wrote on free speech, his works are even more important in science. If people cannot freely question broadly and deeply held beliefs, they risk losing the knowledge of _why_ they are so deeply held by so many. If that ever happens, we will have lost something truly precious.
For applications that don't need hard real-time and/or aren't very high frequency, one could set the CPU frequency governor to always run at max frequency. You're right in that this can be done at runtime without a need to disable CONFIG_CPU_FREQ.
To achieve hard real-time at high frequency (roughly >10kHz), the standard kernel and PREEMPT_RT are not sufficient. One approach is to use a microkernel that preempts the Linux kernel. RTAI and Xenomai are two frameworks that do this. Processes run through them cannot be preempted by the kernel, so deterministic timings can be much better guaranteed. It's in this case that one would disable CPU scaling (along with Intel pstates, ACPI power management, and other things I don't remember offhand) when compiling the kernel. Changes in CPU frequency can change the frequency of the time counters on the CPU, and that opens up a vector for the vanilla kernel to interfere with the timers used by the microkernel and potentially break real-time.
Now, is it true in this latter scenario that one, as I said, "needs to" disable CPU scaling entirely? Now that you've got me thinking about it, probably not. If one guarantees that the 'performance' (i.e. max freq) governor is running at boot, leaving CONFIG_CPU_FREQ enabled may be fine. (The default governor will still need to be changed to the performance one in the kernel config, though.) Setting max frequency at runtime, however, maybe not. This is probably an edge case (I haven't tested this), but if the system boots with a dynamic CPU frequency enabled, the standard kernel, which cannot access information about threads controlled by the microkernel, could scale down the CPU a real-time thread is running on and mess up the timings. Changing the frequency mode at runtime after that happens may not fix that issue.
If I were to write that again, I'd use "should" or instead of "needs to." It's much simpler to disable frequency scaling in the menuconfig while disabling everything else than it is to leave it in and worry about it afterward.
None of this changes the point about real-time and power consumption, though.