This is a bold statement that is outright wrong in my opinion. Please consider editing that post to prevent less technically inclined users falling for this.
An unlocked bootloader allows anyone who has temporary access to the phone to tamper with the boot process and in consequence with the system partition. This enables a slightly sophisticated attacker to implant a backdoor or extract the decryption key/your passphrase while you unlock the phone the next time.
Of course there are layers of trust and not everyone may want to root their trust into the security of an opaque locked boot process. However, I can hardly think of any thread model in which an unlocked bootloader does not compromise the phone’s security in one way or another.
I am aware that this post is off-topic – sorry for that but I felt like this statement needed some additional context.
This should be the case unless there is an unknown issue within the encryption or its implementation. However, the question we need to consider here is whether an unlocked bootloader could make it easier for an attacker to extract or brute-force the key. I am no expert but I’d imagine that this could be the case: As an example, if the bootloader is unlocked it might be easier to circumvent some brute-force prevention mechanisms such as delays or a limit of unlock attempts. If that would be the case, the lock pattern on a 3x3 grid that most users use has a rather small input space and can likely be brute-forced.
Personally, I also use my day-to-day phone with encryption and an unlocked bootloader. However, I would not rely on Android’s encryption and its security model to protect really sensitive data against skilled adversaries. There is so much that can go wrong in cryptography and Android encryption has been criticized in the past for being broken  and not being well designed . Even though this post is from 2016, checking the Android source documentation suggests that not much has been changed since .
Furthermore, given the various proprietary binary blobs running on a common Android phone, potential issues in the trust zone  or even in the hardware (e.g., vulnerable chips with DMA), I personally deem it reasonable to assume that physical access to the device eventually results in data access when dealing with sophisticated adversaries – regardless of the state of the bootloader.
In the case of a lost or stolen phone, Android’s encryption should propably suffice to keep the data secure from the prying eyes of the common pickpocket – at least I do hope so. And in the end it all comes down to your threat model
A variety of devices use file-based encryption (FBE) now, not full-disk encryption (FDE). I think they are the majority (FBE has some user experience improvements, specially the accesibility ones), but I don’t know for sure. I guess the FP2 uses FBE too when using Lineage OS Pie onwards.
Now, the fact is that things has changed, but that’s not saying that data security went any better or the encryption design is perfect now, specially if they still rely on obscure implementations of TrustZone or whatever. Thanks for your heads-up, that was an interesting read!
Lately, I have also been reading a lot about locked vs unlocked boot loader in context of LineageOS on Fairphone , and I would like to add the following points:
Fairphone 3 does not have ‘secure boot’ enabled 
EDL is easily accessible, and a working EDL programmer is publicly known 
Generally, this means that anyone with physical access can put the phone in EDL mode and reprogram it. There is even an published method to unlock the boot loader using EDL, leveraging those issues .
Yes, Android’s encryption helps here. As explained in that same topic, that EDL unlocking method still does not allow access to the encrypted data as it also modifies the encryption keys. More devastating attacks are likely possible though.
To address those issues, I have experimented with enabling avb_custom_key to override the built-in root of trust . Contrary to what is stated here, this seems to work, as I can see that the key has been set in devinfo.bin.
However, that still does not help if ‘secure boot’ is not enabled. Here I got stuck - enabling secure boot requires blowing some qfuses . I think this should be possible with the EDL programmer, but at this point things become risky, with a very high chance of hard bricking the device.
Bottom line: a locked Fairphone 3 boot loader provides additional security compared to an unlocked one, but keep in mind that secure boot will still be disabled, and EDL mode easily accessible, meaning that the additional security is more limited than you might think.
That being said, I do think the additional security is real and significant, so I personally run LineageOS with relocked boot loader (and some additional security measures).
I hope this topic isn’t considered too old to reply.
After having my phone stolen I was a victim of a very expensive crack so security is something I care a lot about.
At the same time, I want to have control over the devices I own.
IMHO the only way to make peace with these 2 that I can think of is to have a small secure element with a second display to display a checksum of the bootloader. Much like Ledger Wallet.
The checksum could be something more easily readable though, like an adjective and noun from BIP32 paired with image art.