[Android Q&A, Help & Troubleshooting] Defier525:
Thank you very much for this call, I highly appreciate it! Me, I consider securing Recovery also very essential, but instead of coding a patch I would like to contribute the overall discussion:

having a locked bootloader normally restricts you to booting a stock kernel without a bootloader-valid signature, right? Otherwise you could simply fastboot any kernel without flashing. But this can be an issue in case your kernel is outdated and has other security flaws which e.g. make it vulnerable from remote. In this case, you secure your device from offline attacks but stay vulnerable to online attacks. The hard questions is: which attacks are more realistic?

in "good old cm7 times", maniac103 implemented a password-protected CWM for the Motorola Defy which was based on entering a password sequence using the sensor keys (back, home, search etc.). See this commit.

many people argue against Android encryption because it is based on the "same password as for the screen unlock". This is essentially not true: It's just the front-end in almost all Stock ROMs which does not support it - the back-end does. You can set a much stronger passphrase for protecting your encryption key using comand line or a tool like this or this (both require root, stupid!). You still suffer from the hardcoded limitations in crypt.c (like only 2000 rounds, just 128bit AES, maximum 16 char limitation etc.) but much better than having just a numeric PIN! Please note that Android 5.0 also tries to store the encryption key in a more secure location than the footer of the disk partition as outlined here.

Even if you could overcome a TWRP password on a bootloader-unlocked device easily by fastbooting a different boot image, it still raises obstacles for a "stupid" attacker (e.g. you need a device with USB and not just a microSD card or USB drive+OTG cable). Although I would still consider it "security by obscurity", in essence, it's going in the same direction as JTAG also being hard(er) to exploit.

The same argument accounts for "dumping your encrypted partition and installing a sniffer" - it raises the barrier and the victim will likely notice that something is wrong (unless it's using a device that's unstable...) because the device will be off or rebooted. A counter-measure would be: if you find your device in such a state, boot into recovery and compare checksums of your boot and system partitions - probably many even more advanced attackers will probably forget to install rogue versions of md5sum/sha256 etc, and of course you could also carry a write-protected USB drive+OTG cable with a clean boot image, provided TWRP would allow you to boot from that (which afaik it currently does not).

Considering the huge security breach of an unprotected recovery, I would consider the option to recover stuff via adb from recovery a secondary objective. A more effective approach which could help against the problem of non-recoverable data from a hardware failure would be having the data already external - like in the approach I posted in this thread where I argue against keeping private data in internal phone memory. Unfortunately, on many devices this will not work with a locked bootloader unless you manage to modify the rootfs elsewise (but I assume recoveries like Philz seem to manage it already somehow with locked bootloaders).

There are many other attack vectors like a memory freeze which a locked bootloader can certainly make more difficult.