According to another commenter, the Trezor uses an STM32F205. A quick skim through EEVblog's teardown and it does look like they use that device, and only that device (no other peripheral security devices).
On a quick skim of the STM32F205's Programming Manual I don't see any mention of RDP or Read protection. In STM32 devices that's the Flash register that prevents readback of data stored in the device's flash and can also disable the device's debug interfaces.
So ... if all that is accurate then the "attack" is very straightforward. Just open the device, hook into the debug interface (SWD/JTAG) and dump the Flash. Easy.
The only way to defend against such an attack is to either 1) Encrypt the contents of the device with a user password or 2) use anti-tamper methods which would erase the device in case of tampering. Since I don't believe the Trezor has a battery, #2 seems unlikely. #1 is already possible on a Trezor, but is optional.
If all this is the case, then yeah ... there's nothing that can be done to stop it (besides the password).
I'm actually really surprised.
When I built my Bitcoin hardware wallet, even before the Trezor, I used an STM32 device that had RDP. With RDP enabled, there's no specified way to dump the chip's Flash and the debug interfaces are disabled (1). I also had a touch screen on the device, so a real password could be used (not just a pin code). Combined with aggressive PBKDF2 iterations, even if someone got into the Flash memory your data would still be protected behind strong encryption.
Also, in a recent re-iteration of the device, I'm actually using _two_ MCUs. One MCU is the communications MCU and the other is the secure MCU. The comms MCU connects to USB, Bluetooth, etc and talks to the secure MCU over SPI. The secure MCU connects to the display and touchscreen. The reason for this split is to prevent any bugs in the USB/Bluetooth/etc stack from allowing access to your secure data.
Unfortunately my real job got in the way and I never finished productizing my hardware wallet. Maybe I should resurrect that project...
Anyway, I'm surprised the Trezor didn't use a more secure STM32 device. It would hardly have cost more.
(1) Of course, it's foolish to trust MCU manufacturers to have good security. For example, in the course of securing an NXP MCU which also has readback protection I discovered a way to bypass the protection and dump RAM contents off a warm device. That's why I planned for strong password protection on my devices, as a second line of defense. I've even considered using an FPGA instead, as, for example, Lattice FPGA devices are designed by competent security engineers. Even delidding secured Lattice FPGAs device will wipe all secrets. But FPGAs can be rather pricey and take more time to develop with.
EDIT: In hindsight, thinking about it more ... if your Trezor doesn't have a pincode, can't someone with physical access to your Trezor just spend your coins anyway? Not much need for a "hack" there.
Of course, lack of RDP is still a problem. Pin codes can be "strong" if the device has RDP, because the device can rate-limit pincode tests. But if you can dump the Flash, then the pincode offers 0 protection since offline bruteforcing the pincode from the encrypted Flash would take no time at all.