If someone obtains your phone, and prevents you from initiating a remote wipe (perhaps they have you in custody, or perhaps they have isolate the phone so that it cannot receive the wipe command), it sounds like this technology will do a good job of preventing them from decrypting your data from the phone if you have a decent passcode. They cannot throw GPUs or FPGAs or clusters or other custom hardware at the problem of brute forcing your passcode because each attempt requires computation done by the Secure Enclave using data only available in the Secure Enclave. That limits them to trying to brute force with no parallelization and 80ms per try [1].

However, assuming they have an appropriate warrant, can't they get your iCloud backups and try to brute force those? Maybe I'm being an idiot and overlooking something obvious, but it seems to me the encryption on the backups CANNOT depend on anything in the Secure Enclave.

That's because one of the use cases that iCloud backup has to support is the "my phone got destroyed, and now I want to restore my data to my new phone" case. To support this, it seems to me that the backup encryption can only depend on my iCloud account name and password. They can throw GPUs and FPGAs and all the rest at brute forcing that.

My conclusion then is that when I get a new iPhone, I should view this as a means of protecting my data on the phone only. It lets me be very secure against an attacker who obtains my phone, but not my backups, provided I have a good passcode, where "good" can be achieved without having to be so long as to be annoying to memorize or type. A passcode equivalent to 32 random bits would take on average over 5 years to brute force.

To protect against someone who can obtain my backups, I need a good password on iCloud, where "good" means something considerably more than equivalent to 32 bits.

[1] I wonder if they could overclock the phone to make this go faster?