TPM is a pretty nice thing to have for a laptop user.
In case your device got stolen but you have enabled full-disk encryption, there is much MUCH less chance that thief can access your data, because key is not directly stored on disk and it can't be easily extracted.
You can benefit from TPM on both Windows and Linux in that way, and also can control TPM in terms of key management.
Every hardware or software component has it weaknesses because of enormous amounts of integration and abstraction levels in modern systems. And it's always better to have relevant revision of any chip.

It is certainly not DRM of any kind, if you wanna see a real hardware DRM take a look at iLok that is widely used in professional software like ProTools.
You literally can't start some programs without USB dongle. Now that is hardware DRM my friends.

Did you look into a system that actually has an up to date release/build of Wine? Debian, rather alarmingly only has 5.0.3 in Stable, whereas Fedora has been testing the 7.0 release candidates, and Slackware doesn't even appear to package Wine.

To any point, on any system that isn't on JWZ's naughty list for never updating, Wine has made massive forward strides in compatibility and capabilities.

For protected mode yes that's probably how it works (Understanding and configuring protected mode to work was always over my head).

The self modifying code I'm talking about MS-DOS and other 286 related systems. Though i remember reading this was a practice, i can't seem to find articles or anything on the subject (Though there are some references in some headers)

Well, if you actually want it to do what it's supposed to do, having it be a tamper-proof IC is an advantage. It is, after all, meant to not only provide hardware crypto acceleration, but also store secrets it does not directly give out. Otherwise, yes, it's possible to emulate either in a VM (Xen and qemu/kvm both do this, I think), or, apparently, AMD and others provide UEFI modules to use the CPU's crypto support for software emulation (although I doubt that extends to the OS; it's probably just for secure boot). It's not exactly the same thing as FPU emulation, though, since FPU emulation is done by the OS to support user programs, and TPM emulation has to actually fool the OS itself and also run before/during firmware boot.

What security? What's the threat model? How a processor that is running unknown code and can't therefore be inspected can add security to anything?

Thank you!

It ensures that your machine is only running vendor-certified code. No viruses, no trojans, and, most importantly, even though MS won't say so, no cracks to remove DRM checks (which are further enhanced by providing a unique per-machine hidden key). This applies to the OS and any user-level software that is protected by the trusted platform.

As to your complaint about the TPM being a black box, it isn't. There are standards, and there are agencies (government and private) which will validate TPM hardware. Maybe you don't trust those agencies, but at some point, unless you reverse engineer every chip in your system with a microscope, you have to trust someone. If you care about your TPM's security, you will need to make sure it isn't just some unvalidated hardware that was thrown in to allow the machine to boot Windows.

I'd rather say: why should we trust them at all? :)
A lot more games will have native Linux versions, when its user-base increases enough to make this platform attractive for game developers and publishers.

Therefore, people who would like to use Linux, should not wait and have to change their OS regardless of native game availability.

The earlier they do it, the sooner Linux will receive proper support from game developers.
You don't need TPM for hardware full disk encryption feature, nor for key management.

CDP runs GOG and CDPR. They're two companies under the same umbrella.