I agree with @PsychoWards and @Todd Miller - we are having a conversation that plagues IT Security engineers all the time.... finding the middle ground of high security and protection but ease of use. Make things to easy and its not good protection. Make the protection as solid as possible and the user won't use it. The general standard dictates the data MUST be encrypted before it leaves the machine.
The standard practice is you encrypt the data, and you store the keys in a Vault (like Bitwarden, 1Password, or a physical safe). HexOS is marketed to "prosumers" who want things to "just work." If HexOS forces encryption and the user deletes their OS without backing up the keys, the data is mathematically unrecoverable.
Should we be storing keys on the HexOS servers? From a security standpoint, this COULD be a huge issue. The risk comes down to the possibility of HexOS getting hacked, the hackers then have the keys to everyone's backup. Buddy Backup aims to be a "zero-knowledge" system, and that should mean only the users have the keys. HexOS server can assist in the facilitation of passing the keys to each user because seeing part of the key isn't the actual key.
They could use an identity-based key derivation like Steve Gibson's SQRL. If HexOS generated a Master Identity Key for each user, the system could automatically derive unique encryption keys for each Buddy Backup target. This would allow for 'Zero-Knowledge' offsite backups without forcing users to manually manage individual encryption keys for every dataset. We get the security of ZFS encryption with the ease of a single Master Password. In a SQRL-style system, if you reinstall the OS, you must have your Master Key backed up. If HexOS doesn't force you to save that master key (or the 24-digit Rescue Code) during setup, then a reinstall would mean the end of your data.