That's a lot of assumptions. Or, as Jayne Cobb might say, "I'm smelling a lot of 'if' coming off this plan."
Those assumptions that you criticize hold true for the realistic threat faced by the vast vast majority of people: opportunistic taking of personal data by device thieves, intruders, and others with physical access to the machine. If you are worried about more sophisticated attacks, then you can easily ratchet up BitLocker's security by requiring a boot-time PIN, dongle, or password in addition to the TPM/SecureBoot measurements. You will also want to be more selective about the hardware that you use.
On a CoreStorage Filevault 2 system, the Recovery HD is used as the boot loader, calling an EFI program named "boot.efi" present on the filesystem.
On a APFS system things are a bit different; the Recovery HD is still used, however this is now a Logical volume presented from the main volume group, with the update to High Sierra a Firmware upgrade was pushed out to all supported systems enabling the EFI to grok APFS.
Edit removed terminal output
* The way that e.g. macOS FileVault works, where you enter your password in EFI, before the machine boots and before the OS is loaded.
* The way that e.g. iOS works, where there is an unencrypted partition containing the OS (mounted read-only), and an encrypted partition containing the data. The OS boots off the unencrypted partition, then you have to enter your password to unlock the data partition.
* The mode you're describing, where the unlocking happens automatically if and only if nothing has been tampered with (the encrypted hard drive hasn't been swapped into another machine, etc). With this mode you're relying on the fact that when the OS boots it won't let you do anything without entering a password, even though the disk is already unlocked. Assuming there are no bugs in the login screen, no way to physically read the contents of RAM (where the encryption keys are), and no way to access the contents of the TPM, this approach is just as secure.