DeletedUser88 Verified boot prevents modifying the firmware or OS images without a sophisticated exploit to bypass verified boot for either the firmware or OS. It also prevents downgrading the firmware past a rollback version upgrade or downgrading the OS past a security patch level upgrade since that's used as the rollback version for the OS and gets incremented every month with each stock OS release in practice, other than a rare case they might do a YYYY-MM-05 security patch level release prior to a quarterly/yearly update with the same patch level later in the month. The hardware keystore rollback protection takes OS version into account though.
An sophisticated exploit of verified boot of the OS could allow surviving factory reset from recovery but not flashing from fastboot mode. Surviving flashing the firmware/OS would require replacing fastboot mode with their own, implying having a lower-level verified boot exploit not only an exploit for OS verified boot performed by the firmware for the core OS and by the OS itself for the rest of the OS.
This is theoretically possible but not something that is particularly likely to have even been developed to work against the stock Pixel OS in practice. How often do regular users even factory reset, let alone reflashing the OS from fastboot mode? It's an incredibly niche purpose for an exploit and it's much harder to develop than a local privilege escalation exploit for the OS. It's also probably harder to develop than a remote code execution exploit in most cases. They would need to find vulnerabilities in a far smaller amount of code which can be triggered while the device boots and verifies the early firmware and later OS images. It's even quite feasible that there are not vulnerabilities to exploit without physical tampering, unlike the massive attack surface of browsers and the OS. Most of the vulnerabilities in this niche would be a failure to implement the basics of verified boot properly rather than a typical memory corruption bug since there's so little attack surface. It's quite possible there are vulnerabilities but it's such a small amount of attack surface exposed by persistent state to the early firmware and OS while verifying.