The TPM2 requirement (and kind of by extension the IOMMU requirement, which is the one itself that bit most people) has significantly more benefits than "DRM" or "planned obsolescence". For one, did you know that TPM1.2 didn't include SHA2? Would you be okay relying on SHA1 hashing in 2026 to be used for digital signing? Of course you wouldn't. If I told you today to go generate an X.509 certificate with SHA1 you're going to look at me funny. Did you know it also didn't include ECC? Also much more useful in this day and age for cryptographic speed. There are many other features I don't feel like digging into at the moment, but you get the point.
I would counter that the downstream requirement for the IOMMU (useful for Hypervisor Enforced Code Integrity), in which Windows itself is broken up into "Virtual Trust Levels" (VTL0, VTL1, and I think there are some newer ones now as well); is extremely useful for securing early parts of the platform boot.
Or did we collectively forget about the early rootkit era of Windows XP from 2005-2010 when running with legacy/MBR boot mechanisms?
Establishing a trust boundary as early as possible to force possible attackers into userspace as much as possible (where it can be more easily removed and remediated) is significantly important in modern operating system security--and this goes for any platform: MacOS, Windows, Android, iOS, or Linux.
Apple, Google, and Microsoft have some form of integrity control over their platforms along with dedicated security chips. Short of some exploits, the most common vector to get into Windows' early boot process is to steal or abuse code IHV kernel driver signing certificates; or in some cases, be maliciously issued one from Microsoft (lol, now THAT is indeed a problem, but a tough one).
This is just part of modern platform security at this point so I don't really see the issue.
In addition, TPM2 offers significantly more storage and