Odpověď na názor

Nejde asi až tak moc o to, jaký je to kód - větvení je v kódu vždycky (i když predikovatelnost se různí, takže trošku to asi působit může)
.
Tady jde ale asi hlavně o to, jestli ten program v první řadě vůbec trápí ty ochrany proti Spectre. A ty ho nemusí skoro vůbec postihovat, pokud funguje tak, že si jede ve svém procesu nebo procesech, nevolá moc systém a I/O a jen si pracuje pořád na svém písečku (datech v paměti), dokud nevyplivne nějaké výsledky.

Aby se dostavil efekt těch ochran (mitigations) proti Spectre a téhle jejich optimalizace, tak musí docházet k přepínání mezi aplikací a jádrem OS, například protože aplikace komunikuje po síti, nebo čte a zapisuje na SSD (vzpomeňte si na to, kde jsme v roce 2018 při řešení těch chyb pozorovali větší propady výkonu - nejvíc to IIRC bylo asi při práci s diskem).
K tomu vyprazdňování BTB a resetování prediktoru větvení, kterého se ty optimalizace týkají, totiž dochází při volání do jádra nebo přepínání procesů. Celá ta optimalizace je o tom, že to přepínání mezi procesy a volání procesů do jádra, které předtím opravy Spectre zpomalily, se teď zase o trošku zrychlí, protože se to bude dělat víc efektivně.

Moc bych se nedivil, kdyby se to v tom Geekbench opravdu neprojevilo (teď jsem trošku googlil a v roce 2018 tehdejší verze Geekbench moc propad neutrpěla, takže to může být ten případ, že vlastně není odkud ten dřív ztracený výkon obnovovat).

Hry ale komunikují s ovladačem GPU, mají nějaký ten datový provoz (i síťový, ale multiplayer se asi většinou nebenchmarkuje?), takže u nich je větší šance, že vám mitigace Spectre žerou nějaký výkon, a tím pádem je prostor pro to, aby se část dostala zpátky tím, že tyhle optimalizace to jejich žraní trošku zredukují.