That is indeed a worst case event to be wary of and avoid, for any secret data that one may need to retrieve infrequently.
But my original point was that sealing the key to the TPM is better because it prevents adversaries from accessing the volume data by tampering with the boot chain, and provides a lockout where there are too many failed PIN attempts.
The bruteforce attack described by the author wouldn't have been possible on a BitLocker volume that was set up with TPM+PIN.
The actual encryption key for the volume data isn't the recovery key, it's the FVEK (full volume encryption key), which is encrypted using the VMK (volume master key).
The recovery key is a 128-bit value (entered as 8 groups of 7 digits, each of which when divided by 11 gives a 16-bit value, where a non-zero remainder indicates the group has been incorrectly entered) which gets hashed repeatedly, with a salt, to derive a 256-bit key that decrypts a copy of the VMK.
BitLocker does this much better. With TPM+PIN mode, the TPM will only decrypt the volume master key if all the right hashes are in the platform configuration registers for the BIOS, option ROMs, MBR, filesystem headers and bootloader, and the user-specified PIN is correct. Or if you enter the 128-bit recovery key.
The BSDs and Linux have a lot of catching up to do.
But my original point was that sealing the key to the TPM is better because it prevents adversaries from accessing the volume data by tampering with the boot chain, and provides a lockout where there are too many failed PIN attempts.
The bruteforce attack described by the author wouldn't have been possible on a BitLocker volume that was set up with TPM+PIN.