This doesn't work with GrapheneOS but rather you can create a derivative of GrapheneOS without the core security model intact. Instead of a tiny core portion of the OS being trusted with root access, a massive portion of the OS is trusted with that. It's much easier for an application to compromise the OS. An attacker doesn't need exploits for privileged persistent compromise anymore but rather that's a given since the verified boot security model is no longer intact. The purpose of locking the bootloader is enabling verified boot, which is no longer intact with this approach. CalyxOS doesn't have a complete verified boot implementation for the OS like GrapheneOS and rolls back the standard security model a fair bit, but doing this rolls it back far more. You cannot have your cake and eat it too in this case. If you want modifications to the OS, you should use the official build instructions and avoid replacing the core of the OS with a rootkit trusting a massive portion of the OS to give out root access and trusting persistent state with root access.
avbroot is not officially supported by CalyxOS or GrapheneOS, but it does work with both OSes. The point of avbroot is to make root access available to trusted Android apps while leaving commands such as "fastboot flash" and "fastboot erase" disabled.
There will always be a subset of users who prioritize functionality over security. This includes anyone who would root an Android device (and anyone who would use a desktop computer running most distributions of Linux, macOS, or Windows).
I'll be glad to reconsider using root on Android if all of the functions of App Manager's "block trackers" feature[1] and Basic Call Recorder[2] were available on Android without root.
No, it's not compatible with receiving official over-the-air updates. Similarly to if you build and signed the OS properly, you'll need to make each of the updates yourself. Unlike building and signing the OS properly, you will not have the basic security model intact but rather will be massively rolling back security and trusting a huge portion of the OS with root access. Giving root to a massive portion of the OS destroys the fine grained access control and isolation model used throughout the OS. It makes exploitation much easier to do and much easier to hide. It also makes persistence a given since persistent root access can be given out which means an attacker doesn't need any verified boot bypass anymore. It's odd to go through all this effort to continue signing the OS for verified boot while losing the main verified boot security model which makes it useful.
If you want root access, build and sign userdebug builds with ro.adb.secure=1, which is officially supported by GrapheneOS and only exposes root access via ADB which you should only use from the computer where you're building the OS.
It would be possible to add some kind of key combination at boot to disable loading user installed applications, etc. and instead making a terminal with root access available. Not clear how that's really useful though. Instead, what these projects are doing is giving out root access to a massive portion of the OS in order to be able to give out full root access to apps. This is used as a shortcut to implement features in a way that massively reduces security even if you never use it. Implementing those features properly integrated into the OS following the principle of least privilege is the proper approach. Most of the features people believe they need this hack to achieve are doable without it, such as filtering traffic with your own firewall rules while also using a VPN which is a standard Android feature available to apps.
https://github.com/chenxiaolong/avbroot
Works great with CalyxOS and GrapheneOS.