Encrypted updates will probably never happen on Teensy 3.x. Without a reliable hardware mechanism for storing & using the encryption key, security is at odds with "brickability". Even if you're willing to risk your own hardware, that's a rather dangerous path (easily brickable hardware) for PJRC to take. Even then, I'm pretty sure schemes we could actually implement on the Teensy 3.x hardware would have significant security holes, making them mere "speed bumps" to anyone seeking to copy your firmware.
I am seriously considering this for Teensy 4.x. The main difference is the hardware has secure key storage which is integrated with an encryption engine and a secure boot process (baked into the hardware) to support it. The really important hardware feature is managing the secret key. The 128 bits are burned into permanent "fuse" memory, then 2 more lock fuses are available. The write lock prevents any further changes to the key. The read lock makes the key forever unreadable to software, but the encryption engine has a direct path to actually use the key. The ability to properly manage the key, so it can be used, but can never be read again by anyone in physical possession of the hardware is the essential ingredient needed to really make encrypted firmware update secure.