It's unencrypted in RAM before it's suspended too. My point is that the SSD is non-volatile storage. Worse, your keys or private data would likely stay there even if you subsequently rapid-start, unmount, scrub keys from RAM and do a full shutdown.
Encrypting the root file system or whole disk would require scrubbing the keys from RAM before suspend, being able to prompt for credentials on resume, and reattach. One-time keys for encrypted swap would have to be written into that secure storage area too and somehow re-opened. You still have to hope nothing confidential remains anywhere in RAM. And/or do a scrub of the rapid-start partition after resume, hoping the SSD is actually overwriting the same blocks.
In summary, if the machine might be still logged into something non-public, like a website account or email box, or has been used to view/create/store anything since booting that should stay private, this feature is junk and you wouldn't want to use it.
Re: Threat to dm-crypt
Encrypting the root file system or whole disk would require scrubbing the keys from RAM before suspend, being able to prompt for credentials on resume, and reattach. One-time keys for encrypted swap would have to be written into that secure storage area too and somehow re-opened. You still have to hope nothing confidential remains anywhere in RAM. And/or do a scrub of the rapid-start partition after resume, hoping the SSD is actually overwriting the same blocks.
In summary, if the machine might be still logged into something non-public, like a website account or email box, or has been used to view/create/store anything since booting that should stay private, this feature is junk and you wouldn't want to use it.