Hardware

but all they would need to do is look at like the top 100 games played every year

My main hypothesis on this subject - perhaps they already did, and out of the top 100 games only 2 games was possible to accelerate via this method, even after exhaustively checking all possible affinities and scheduling schemes, and only on CPUs with 2 or more 4-clusters of E-cores.

The support for the hypothesis is the following suggestions:

1. how many behavioral requirements the game threads might need to satisfy
2. how temporally stable the thread behaviors might need to be, probably disqualifying apps with any in-app task scheduling / load balancing
3. the signal that they possibly didn't find a single game where 1 4-core E-cluster is enough (how rarely is this applicable if they apparently needed 2+, for... some reason?)
4. the odd choice of Metro Exodus as pointed out by HUB - it's a single player game with very high visual fidelity, pretty far down the list of CPU limited games (nothing else benefited?)
5. the fact that none of the games supported (Metro and Rainbow 6) are based on either of the two most popular game engines (Unity and Unreal), possibly reducing how many apps could be hoped to have similar behavior and possibly benefit.

Now, perhaps the longer list of games they show on their screenshot is actually the games that benefit, and we only got 2 for now because those are the only ones they figured (at the moment) how to detect threads identities in (possibly not too far off from as curiously as this), or maybe that list is something else entirely and not indicative of anything. Who knows.

And then there comes the discussion you're having, re implementation, scaling, and maintenance with its own can of worms.