That's about what I was expecting to hear: it just seems to me peculiar that makers still use a socket to provide a TPM, when it is surely easier to do it in the software.
...
It may be you're wondering...as have I...why they'd use a socketed TPM device if CPU's all have built-in devices these days. I think it's for ease of decommissioning a computer after it's service life is up.
As I understand it the TPM is used for device attestation purposes: it attests that the machine is running un-altered software on un-altered hardware and operated by a user using a valid PIN, password, bio-metric, whatever. It also holds the keys for accessing BitLocker encrypted drives. It makes sense that attestation would be required by the security policy before allowing a machine on a corporate network both locally and especially remotely. It will be done at every bootup, before accessing the network and interactively whenever accessing areas with increased sensitivity. The TPM holds all the keys or hashes or whatever in a highly secure way and updates them interactively whenever an administrator makes approved changes to the machine.
Apparently, that all works the exact same whether a discrete TPM or fTPM. So it seems to me a discrete TPM becomes invaluable when it's time to decommission a system since you'd want all that removed from the machine to resell it. Removing a CPU destroys it's value...removing a discrete, socketed TPM doesn't. It can be easily done by unskilled IT helpers and takes a lot less time than clearing TPM storage since it doesn't need to power up the machine. You might even leave the drives if you use and trust the bitlocker encryption, further increasing value of the used systems. And lastly: it also makes easy auditing before the truck rolls out with the old systems: 50 systems going to auction, 50 TPM keys in hand with matching property tags.