L'implémentation de HT s'est améliorée depuis les débuts où il avait été montré que des workloads comme MySQL détestaient l'hyperthreading, avec des pertes de performance significatives. Il reste cependant qu'en l'absence d'informations d'affinité, si le scheduler trouve malin de mettre deux threads qui utilisent les mêmes blocs du processeur sur les 2 hyperthreads du même coeur, plutôt que sur 2 coeurs séparés du même socket, la performance peut être inférieure, et surtout, non répétable.
Sur certaines micro-architectures, la performance inférieure peut aussi être remarquée quand on utilise tous les threads du CPU: la performance de memtest86+ (scheduler statique trivial) avec tous les threads est inférieure à la performance avec 1 seul thread par coeur, malgré une consommation électrique et un dégagement de chaleur habituellement supérieurs. `rep stosl / rep stosq`, ou de courtes boucles similaires, ne s'exécutent pas toujours (voire pas souvent ?) efficacement en parallèle sur 2 hyperthreads du même coeur. La pénalité de l'utilisation du SMT est certes inférieure à celle qu'on rencontre sur certaines machines quand on ne tient pas compte du NUMA (j'ai vu un facteur 15-20 sur une machine Ivy Bridge EP quad socket !), mais elle existe.
Je pense que sur certains workloads, pour avoir des benchmarks fiables, il est encore plus simple de désactiver le SMT que de programmer d'une façon ou d'une autre l'affinité de manière à éviter le SMT.

Et côté vulnérabilités des processeurs, désactiver SMT fait partie des mitigations de L1TF ("Foreshadow-NG"), MSBDS ("Fallout"), MFBDS ("Zombieload"), MLPDS et MDSUM ("RIDL"). Un certain nombre de mes machines tournent sans HT depuis 2018.