Because unless you make hyperthreading a purely opt in thing, there is no way to know as a kernel if two things that are security sensitive relative to each other are being run on the same core as Hyperthreading neighbors.
Two threads in a web browser that are assigned to different websites for instance.
> there is no way to know as a kernel if two things that are security sensitive relative to each other
The kernel has a way, and it is process isolation. The kernel doesn't care if you want two threads in the same process to be isolated from one another - that's your problem, not the kernel's.
Anyway, thread isolation already doesn't work even without hyperthreading-specific attacks: "we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels. In the face of this reality, we have shifted the security model of the Chrome web browser and V8 to process isolation" (from https://arxiv.org/pdf/1902.05178v1.pdf).
Chrome doesn't exclusively use process isolation, several sites will share the same chrome process. This is only one example, another might be for instance, authenticating users on one thread, and sensitive authenticated data on another, which is an extremely common pattern.
My point is that the OS has no responsibility to isolate threads from one another, regardless of how many applications may try to do it themselves anyway.
Two threads in a web browser that are assigned to different websites for instance.