You have a fundamental misunderstanding of what AVB is used for.

Fully supporting and using AVB grants protection against persistence of *all* kinds. If an attacker gains privilege escalation through a remote attack, persistence become much easier if the system is not cryptographically verified every time the device boots.

Keystore and Attestation also rely on the bootloader being locked. If the hardware root of trust reports the device as untrusted, there is a broken chain of trust for biometrics, encrypted app data that uses the hardware keystore, and any form of attestation checks (like AOSP's Hardware Attestion API) will report the device as untrusted.

Going back to the first point, if it is possible to modify the system and gain persistence, there is also the possibility of modifying the kernel, which would allow an attacker to rewrite or patch the kernel, rendering AOSP's sandbox useless.

This would also make it more vulnerable to downgrade attacks because rollback protection is tied to a locked bootloader and AVB.

This could all be accomplished through remote exploitation. The "software side" you speak of is built atop AVB as a minimum requirement to assure that the software you're running is unmodified and intact.