Surprised this wasn't implemented as whole filesystem encryption and then just overwriting the secret key in the SE instead of dealing with the time/battery cost of an incomplete wiping of "passcode-protected data."
When you design protocols like this, the big question is whether there is a bias in the salt and verifier keys that get installed in the SE at the time of manufacture. It's a good design as described in principle, assuming there is sufficient entropy in those 128-bit values, as we tend to assume the field size is what provides the security, but really, it's that there are this many sufficiently random bytes from that field that provides the assurance. If you have seen how crypto gets backdoored in practice, key length doesn't matter if the RNG is hobbled in a deniable way.
Personally and armchairing it, if I were solving this problem I would work more on brute forcing collisions in sensor/image sampling human fingerprints than bothering with crypto and side channels. But in terms of the real threat model, it makes more sense to approach it from the perspective of what the whole product truly is and what it provides.
From a product perspective, designing iPhone security is such an interesting problem because the whole brand image is predicated on being the best available, so you can't do an "oops, sorry" like an inferior product. You can only do what you know you can do better than anyone else. The real threat model is the brand damage from a company like Cellebrite or NSO getting caught or leaked about.
Oddly, the north star for a product like that is probably the U.S. 4th and 5th Amendments, as from a security feature perspective, you can always evaluate whether a design is aligned to those as the sufficient and necessary criteria.