Thanks @Stefan for moving the post!
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