The issue isn't that they didn't work, as I said I wasn't expecting them to when I bought the mouse.
The issue is their behavior has started changing with updates. I don't mind, but I'm a tinkerer. My wife, my MiL, most of my friends, absolutely do not want to deal with an inconsistent computer experience.
Different definitions of 'ready' I guess. Been using primarily Linux for years, so it was 'ready' for me back then - but nothing has changed in the mean time that would change my recommendation for people who just want a boring stable computer.
Many games use multiple threads, but they don't do so very effectively.
The vast majority of games use Unreal or Unity, and those engines (as products) are optimized to make the developer experience easy - notably NOT to make the end product performant.
It is pretty common that there is one big thread that handles rendering, and another for most game logic. This is how Unreal does it 'out of the box'. It also splits the physics calculations off into multiple threads semi-automatically, and the standard default setup will have render and game logic on separate threads.
Having a lot of moving characters around is taxing because all the animation states have to go through the main thread that is also doing pathfinding for all the characters and any AI scripts that are running.. often you can't completely separate these things since where a character wants to move may determine whether they walk/run/jump/fly/swim and those need different animations.
This often leads to the scenario where someone with an older 8+ core chip is wondering why the game is stuttering when 'it is only using 10% of my cpu' - because the render thread or game logic thread is stuffed and is pinning one core/thread at 100%.
Effective concurrency requires designing for it very early, and most games are built in iterative refinements with the scope and feature list constantly changing - not conducive to solving the big CS problem of splitting each frame's calculations into independent chunks.