Sorry I didn’t explain correctly and certainly what I have written previously is misleading. I had been thinking at the time during various dirty flash swaps between systems that have failed to boot for for me it was because even though the device was unlocked, it still possibly had some ability to detect the underlying system had changed and then prevent the ability to decrypt. But that was late night triple thinking something and the last two layers of thinking were not formed correctly. 
So I don’t know why it is needed sometimes to “Factory Reset” if a dirty flash fails to boot, but I have seen that (for seemingly unrelated reasons).
However, I was also under the impression that since the OTA process is able to perform a build signature verification and not allow the install if new new update has a different signature, that we would also be able to inspect if a current running system had a tampered with base, so that possibly from recovery or fastboot we could inspect the current system to see if it matches what we expect from upstream. But that isn’t the case (more late night over thinking going on: are you detecting a trend? The answer is no over thinking past a certain time for me but how do we enforce that? )
In summary, you are correct if physical access to your device by a malicious actor is suspected then to be certain you won’t be the next (or first ) victim of an evil maid you would need to reflash the device before you would login to it and thus decrypt userdata.
So in summary, a locked bootloader doesn’t better protect the data itself (this is the same as if it had an unlocked bootloader), but its does prevent booting if the system is changed out from under you, effectively “confirming an evil maid visited” We won’t know if the evail maid paid a visit if it doesn’t have a locked bootloader.
Sorry again to be spreading misinformation previously.
I do personally remain unworried that any evil maids will be visiting me but to each their own