Automatic reboot is used to restart the device after a user-determined period of time where the device is inactive.
When a device (and user profile) have been unlocked once by the user, sensitive derived encryption keys run within memory to allow the disk encryption/decryption while in use. People determine this state as After First Unlock (AFU) while a state where the device has not been unlocked at all as Before First Unlock (BFU). These descriptions are common amongst exploit developers and forensics analysts. Automatic reboot is an overall security improvement but for most people they use it as an anti-forensics feature.
When a device or profile is in a BFU state - the attack surface is much less, there is no keys in memory, less OS components are running, the device runs in a limited state among many other details. For an exploit to work against a BFU device they'd need an extremely sophisticated and unlikely to be performed attack, an example being to brute force the device's PIN would involve exploiting the tamper-resistant secure element before even attempting the brute force process.
The recent affair involving the project discovering exploits used by forensic companies is directly related to this. The exploit involved bypassing protections in Fastboot firmware to perform a RAM dump after an unsafe reboot, allowing a company to brute force the encryption keys from that dump without any throttling, completely avoiding the secure element's protections. This attack is only possible in AFU. Many forensics companies rely on phones being AFU to extract data, although some companies may be able to get data BFU depending on device manufacturer, OS version and many other circumstances.
We always had the autoreboot, but for the current affair - it was decided to reduce the timer from 72 hours to 18.
If a user sets automatic reboot to a time low enough that suits them, they can keep the phone at the most secure state when they aren't around it but need to keep it on. This does come with the cost of notifications for apps, except for alarms and default calls and texts (providing you don't use a SIM pin). Manually restarting and powering off in sticky situations is always the best choice though.
GrapheneOS also takes additional steps in User Profile improvements, as user profiles run with their own separate encryption keys, and can be purged from memory at any time with the End Session button unlike the Owner profile, which needs a device power off or restart. This is why users of GrapheneOS working in high security setups make the owner profile empty and just manage everything in separated profiles, as if someone breaches the Owner profile, they can't breach the other users if they haven't been unlocked once or had their session ended.
