It looks likely that the Secure Enclave has no storage of its own, so this same attack would still apply.
What would make you secure here is having a password sufficiently long and complex to make brute forcing infeasible. Touch ID facilitates that by making it practical to use the device even with a strong password set. But if you have a four or six-digit passcode set on such a device, then this technique should still work fine.
I haven't done much research on this, but I thought the secure enclave actually did contain the key in question? I know the secure enclave enforces the 10 tries rule (and the timeout between tries), which suggests that the secure enclave is responsible for destroying the key when the rule is violated.
As far as I know there's no official word on this. I say that it probably has no storage based on a couple of things:
First, the iOS security guide makes no mention of any storage besides the flash. When it discusses key erasure, it's always about Effaceable Storage, which according to the guide is a dedicated area of NAND flash.
Second, Apple says that the attack the FBI wants them to carry out could be made against all iPhones. If the Secure Enclave had its own storage, it would be trivial to have it wipe the device if the SE software was updated without a passcode, which would defeat the requested attack. It's possible that the SE has its own storage and Apple just didn't use it this way, of course. Or whoever said this on behalf of Apple could just be wrong that the more recent phones are vulnerable.
The SE does enforce the escalating timeouts, and probably the wipe after ten tries, but that wipe could just be the SE telling the Effaceable Storage to erase the key.
The SE doesn't wipe when it's updated without a passcode because that would completely remove the ability to fix devices that get stuck at the "Connect to iTunes" screen without wiping it. And a non-trivial number of devices end up in that state every time Apple releases an OS update, so maintaining the ability successfully recover from this state without wiping the device is important. They can't just add a passcode entry to that screen because that screen is rendered by iBoot, which has no idea how to handle touch input or any of the other prerequisites for doing passcode entry (it can barely even draw that "Connect to iTunes" screen). And they can't add the passcode entry to iTunes without making it possible to send passcodes over the wire, which is exactly what the FBI has asked Apple to implement (well, that and disabling the wipe-after-10-failures bit).
That said, you can bet that Apple is working on a fix for this for future devices. Some way for the Secure Enclave to know that the update was authorized by the user even if the device was subsequently bricked by the update and then recovered. With the ability to maintain proof of authorization even after the device is bricked, they can then make the SE wipe itself if it's updated without authorization.
Sending passcodes over the wire would be fine. That parenthetical you threw in there is the feature that actually adds security. An inability to submit passcodes over the wire adds essentially no security. It's the escalating timeout and eventual wipe that prevents brute force.
And fixing a stuck device like that could be done by just not upgrading the Secure Enclave's software during the recovery process. Restore the main OS and you're back where you were. Then you can update the SE firmware.
I'm pretty sure that if the SE doesn't wipe when updated without a passcode, it's because there's no way for it to do so. It just loads the firmware it's presented at boot, no questions asked beyond verifying the signature on that firmware.
No doubt Apple is working on improving this. You'd only need 256 bits of nonvolatile storage within the SE, and corresponding improvements to the SE's bootloader.
You can't just restore the old OS, because it bricked during OS upgrade and you can't downgrade. So it has to restore the new OS, which means if the OS update includes an update to the SE, then the SE needs to be updated with it.
As for sending passcodes over the wire, Apple really doesn't want to have this because it makes it a lot harder to reject requests like the one the FBI is making. Disabling the wipe-after-10-passcodes is just turning off a bit of code, that's not an "undue burden", but implementing the ability to send passcodes over the wire is a non-trivial engineering effort and becomes an "undue burden" when the FBI requests that it be added.
I'm sure Apple could figure out a way to allow repairing this problem while still hardening the Secure Enclave against this attack. They just haven't, because it seems that their threat model didn't previously include themselves an a potential attacker. I'm sure that's changing now.
Submitting passcodes electronically doesn't really make that much of a difference. It takes at least 80ms to try a passcode that way. Require touchscreen input and you've bumped that up to, what, a second or two? Without the escalating delays and potential wipe, a (very bored) person could crack a four-digit passcode by hand in a day.
Also, did they remove this functionality? The "IP Box" brute forcer submits passcodes over USB. Apple may have removed that when they patched the vulnerability that allowed bypassing the escalating delays, of course, but it did exist.
I don't know why the FBI requested this ability, but it's presumably just something like, while we're here we might as well make things a little easier.
What would make you secure here is having a password sufficiently long and complex to make brute forcing infeasible. Touch ID facilitates that by making it practical to use the device even with a strong password set. But if you have a four or six-digit passcode set on such a device, then this technique should still work fine.