How is bootloader state protected against physical tampering in Google Pixel
Pixel refuses fastboot flashing unlock (and unlock_critical) command unless OEM unlocking is enabled. OEM unlocking byte is stored by TEE as implemented in android source.

libese
provides a minimal transport wrapper for communicating with embedded secure elements. Embedded secure elements typically adhere to smart card standards.

TEE is tamper-resistant by design. So it's not possible to physically modify OEM unlocking byte in Pixel. VerifiedBootState is also stored in TEE. This ensures that stolen Pixel device cannot be reused by unlocking the bootloader and reflashing the images.
When bootloader unlock command is executed, bootloader queries TEE to get unlock ability set by OEM unlocking. When VerifiedBootState is set to unlocked, TEE flushes file based encryption (FBE) keys and bootloader resets the device. Verified boot state and unlock ability remains persistent in TEE across reboots, flashing custom ROMs and factory reset. This is why the user still has to relock the bootloader even if all partitions are reflashed with stock images.
Verified boot state in TEE is now also used in SafetyNet's hardware-backed attestation. Tamper-protection by TEE makes it impossible to fake verified boot state. As a result, it leaves no way to pass SafetyNet's device-integrity test even if you have root access.
In other devices, OEM unlocking byte is stored in FRP partition which is a bad security design because OEM unlocking byte can be physically modified if it's stored outside of TEE. In such devices, OEMs sends unlock.bin signature file to the user which is used as an additional argument with unlock command so there is some sort of verification in place to verify the device owner. In Mi devices, OEM unlocking requires registration with Mi account which ensures that only the account owner can unlock bootloader from Mi unlock tool even if OEM unlocking is enabled.
Earlier Mi devices are found to be storing bootloader state in /devinfo partition which is totally insecure because by simply modifying the byte, the attacker could unlock the bootloader. As more and more devices will be mandated to enforce SafetyNet's hardware-backed attestation, VerifiedBootState will be stored in TEE.