Why is PCR7 binding not possible when booting Windows from other boot manager?
PCR7 is the register which logs all Secure Boot parameters – the full contents of PK/KEK/db, as well as the specific certificates used to validate each boot application (i.e. rEFInd, Bootmgfw, Winload.efi).
BitLocker appears to have a deliberate restriction that it will only bind to PCR7 if its value indicates that the entire boot chain is signed exclusively using Microsoft's "Windows Production PCA" certificates. It will refuse if something along the way (e.g. rEFInd or other third-party bootloader) was signed using a different certificate, even if that other certificate is trusted by your UEFI configuration.
This is most likely meant to isolate operating systems in a dual-boot environment, e.g. prevent someone from simply rebooting into arbitrary unsecured Linux via Shim and gaining access to your Windows files that way.
(Note: BitLocker's PCR7 usage does not prevent you from having custom certificates installed in PK, KEK, or db – it's okay to have a custom-keyed Secure Boot setup for Linux purposes, as long as those custom db entries don't participate in the Windows boot process.)
Of course, if Secure Boot is off and rEFInd wasn't signed at all, then PCR7 has no useful information in the first place and cannot be used.
How can I fix that?
If you are using the "Device Encryption" feature (Windows 10 Home/Pro), you cannot avoid this – this trimmed-down version of BitLocker always requires Secure Boot and TPM PCR7 usage.
If you are using the full version of BitLocker (Windows 10 Pro only), all of this doesn't prevent BitLocker from using the TPM in general – it can still use the alternative method of binding to PCR0/2/4/11 (PCR4 is the register containing the exact hashes of boot files). The problem is that PCR0/2/4 usage is slightly more fragile and tends to result in Recovery Key prompts more often. For example, every time you update Shim or rEFInd, the PCR4 value will change and you will need the recovery key.
Finally, usage of the TPM isn't actually mandatory for BitLocker. If it's causing too many problems, there is a Group Policy setting and a manage-bde command which will allow you to use a basic password-based protector instead. (Again, this only works with the full BitLocker in Windows Pro.)
(Note: If you enable BitLocker with PCR7 binding active, then reboot via rEFInd so that PCR7 is now unusable, you will be prompted for a recovery key and BitLocker will automatically re-bind against PCR0/2/4/11 instead. And vice versa, rebooting from UEFI menu directly into Windows will cause BitLocker to try re-binding against PCR7 after the recovery key is input.)
My suggestion: Just always use the firmware-provided UEFI boot menu to select your OS. If it's ugly or inconvenient, then use the "BootNext" feature via efibootmgr --boot-next or bcdedit.exe /bootsequence to directly boot into the requested OS. (This even allows you to have "Linux" as a Windows desktop shortcut, for example.)
I think BitLocker isn't limited to encrypting the whole disk.
BitLocker in "Software encryption" mode never encrypts the whole disk – it encrypts the Windows partition, exactly like one would use LUKS to encrypt their Linux partition.
All other partitions remain unaffected. In particular, because UEFI firmware generally doesn't have built-in BitLocker support, the "EFI System Partition" has to remain unencrypted.
Is it possible to use two UEFI partitions?
Yes, but 1) you don't need to, 2) it won't really help you. There is no difference between using two partitions, and putting both Windows and Linux boot files in the same partition – only the files themselves matter at all.
