My guess is they increment the guess count before doing the hash or anything else. Thus even powering down the system at some opportune moment would not not stop the increment. The limit check can also be done before hashing. Likewise erasing the AES key. Lots of people claim that Apple erases the data. They do not, just the key in the SoC and that is done in a microsecond.
Bus analysis says that happens. I did think about power cycling the SoC before guess count was incremented, but analysis of timing said that your posit is correct. Pass/non-pass is stored before it’ll do any communication with the OS.
I’ll go a little further.
I can’t even *see* how many PBKDF2 runs iOS does with the password and salt (salt being the UID, I think). That is an attack vector, but a very very weak one. And you need the UID, which doesn’t appear on the bus until the SoC has done its malarkey.
Very solid system, IMHO. And that comes from a guy who used to design missiles.
When iOS 8 first came out, there was a hack that could allow you unlimited tries. It was exactly that: powering down the system just after the passcode attempt popped up the try again screen, but before the guess counter was incremented. Slow, but it would not ever reach the tenth try. It took about two minutes between tries, so on a four digit passcode, you'd be looking at 20,000 minutes to try every possible passcode. Tedious, but do-able. However, Apple fixed that with iOS 8.2 and later.
You are right about erasing the data. It would take too long to securely erase 13 plus gigabytes or more on larger iOS devices of data even on a Flash drives, but eliminating the passcode HASH is just as effective for all practical purposes.
However, an iPhone can be reset to factory clear, with zero data, in about five minutes. Android devices have been found to be not so capable of being securely erased.