TPMs can't be used to control which software you can install. All they can do is prove what software you're running, which means that a remote provider can choose whether or not to provide a service based on what you're running. Trusted Boot is about providing proof, not about enforcing local policies. Secure Boot can be used to restrict which software you can install, as demonstrated in Windows RT. But that has nothing to do with TPMs - iOS behaves in the same way without using any TPMs.
So I don't really understand the article. Placing trust in TPMs to maintain your secrets obviously depends on you trusting the TPM manufacturer not to hand over any of the secret keys, but having a TPM doesn't mean that you have to place trust in it.
For all of you who (somehow) don't recognize the UID here, this isn't just some "interested observer", this is the person implementing support for booting Linux on systems with these TPMs. In fact if I understand it right Linux can now optionally use a TPM to verify that kernel modules are only loaded if cryptographically signed.
TPMs are also pretty handy for low-level corporate security. Setup disk encryption, store in the TPM then either boot directly (allowing RAM attacks) or require a PIN (requiring someone to break the TPM itself). That's a pretty nifty feature for general security.
I think the distrust and confusion around TPMs and so on is due to Microsoft's moronic handling of Vista's protected playback system and people have extrapolated from there.