starglider In the FAQ, we see "The secure element also provides insider attack resistance preventing firmware updates before authenticating with the owner profile."
On my Pixel Tablet, I have the option to reboot automatically enabled. So, after GOS releases an update, I wake up to a fully-updated device where no action from me was necessary at all
This was explained clearly once by the project account. I just went looking for that and didn't find it right away, so I'll take a stab.
I think the key part of the quote is that the secure element's insider attack resistance feature prevents updates to the secure element's firmware without a user authentication. My memory is that the OS can offer the secure element a firmware upgrade at any point but that the secure element doesn't need to take it. The secure element won't take an update unless it's signed by Google, and the version number is larger than what it's currently running. But the "insider attack resistance" feature is that it also won't take a firmware update until it's been unlocked with the owner password.
My understanding is that the threat being addressed here is very specific. Since the secure element is where key-derivation rate-limiting happens, if it were possible to replace the normal version of that firmware with a version that doesn't rate-limit, then an adversary could brute-force short keys in a short period of time. This means that Google (the company and individual employees) might face demands from some government to sign secure element firmware versions without rate-limiting. If your device were running version 11 of the secure element firmware, and Google were forced to sign an OS update including a "special" version 12 of the secure element firmware without rate limiting, then Google (or specific employees) might be forced to indirectly enable unlocking of locked devices.
With the "insider attack resistance" feature, it is still possible for Google to be coerced into issuing an OS update containing new secure element firmware, and the OS update containing that new firmware might well be automatically installed, but when the new OS boots and offers the update to the secure element it will be rejected. The OS can offer the update whenever it wants to, but if the device is locked it will remain on the old firmware and the old firmware will continue to impose rate-limiting. So the hypothetical firmware that could enable quick unlocking of the device can't be installed until after the old firmware unlocks the device.
In other words, though it's theoretically possible to force Google (or an employee) to prepare easy-unlock firmware, the easy-unlock firmware can't be used to easily unlock locked devices, so in a sense it's pointless.
Further information: https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html