In a nutshell, the TPM works great as a trust anchor if it’s only needed once during boot-up. But anti-cheat and DRM software run concurrently with the software payload, so it’s not a one-time deal but a continual process to reverify. More so, the TPM is not self-enforcing so there would have to be software which issues a challenge to the TPM, and then interprets the response. This uses CPU power, at a minimum.
The crucial challenge – likely unsolvable in the general case – is that anti-cheat software has to try to monopolize some portion of the machine, to prevent running other software like hacks or keygens. But this is diametrically opposed to the goal for the past 60 years of multitasking operating systems and context-switching CPUs, which try to divy out the machine so different software appear to run almost simultaneously and independently.
As a result, some anti-cheat software is truly horrible, because they have to employ very strange tricks to coerce the system to either prevent something undesirable from happening, or to act as a canary when something undesirable has happened. The definition of “undesirable” is left to the software package makers to define.
The only plausible way I could see the situation improving is if OS makers integrated anti-cheat and DRM into the scheduler (the very core of an OS) in a uniform manner. But this is: 1) really complicated, and 2) a security nightmare if malware could exploit it. And that’s ignoring whether the Unix/Linux/BSD world would ever tolerate such a kernel feature.