PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover.
> with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs.
A vTPM is as real as a physical TPM chip.
The question is which TPM endorsement certificate CAs you are willing to trust.
For some that might the manufacturer of TPM chips, for others it might be their VM provider. (For some, none: for some both!)
Trusting their VM provider isn't so crazy if the VM provider is able to influence the guest code anyway.
You don’t need that if you include quote in CSR and then CA validates the quote and writes the validation result in the certificate. Certificate then contains proof that private key is in TPM.
That said, TPM quotes are attesting the value of TPM PCRs which are just registers of hashes (representing the state of the machine).
When making a CSR, you can use https://tpm2-tools.readthedocs.io/en/latest/man/tpm2_certify... to attest a key is TPM-resident.
I think your central thesis is that at the time of TLS establishment, why not use PKCS11 (with a cert signed by a CA that has validated a TPM certification), and I agree: services should probably integrate via PKCS11.