Maybe we're not talking about the same scenarios/alternatives? If I've set up whole-disk encryption with a security level I trust for my persistent storage, how is that not appropriate for the persisted hibernation state? To me, hibernation state is a subset of persistent storage needs, not some categorically different thing. The coupling between running system and persistent state seems so strong to me that I consider them one equivalence class of data and requiring one consistent protection standard.
I adopted the conveniently offered, software-based whole disk encryption mode when installing Fedora. A luks-encrypted LVM PV is the only luks mapping at runtime, and a naked /boot volume is the only volume not allocated as an LVM LV in that encrypted volume group. Thus, I have selected my storage security posture. I expect the cold or detached storage device to be resistant to inspection. Due to the unencrypted /boot, I have doubts that there is tamper-protection of the future running software, should I temporarily lose control of the physical device. I have no illusion that the running kernel lacks access to the plaintext content.
My swap is an LV in that encrypted volume group. Why is hibernation disabled on Fedora? This is where I feel like there is a poorly communicated threat model or some other unstated assumption that I do not appreciate. (But see my last paragraph below for a possible answer!)
Are people concerned about the written hibernation state using the same key as the filesystem volumes? I.e. that knowing how to unlock the whole-disk encryption means you can reconstruct the hibernated image too? I don't see why I, as a user, should care to protect the hibernation image even more than all my regular data. Similarly, if I have the key I can potentially attack the root volume (while offline) to inject all sorts of malware, such that I could exfiltrate RAM state from the running system in the future. Swap isn't required to open me to that attack.
Are people concerned about regular swap state being available on disk during system operation? I.e. the running Linux luks mappings can be abused to inspect swap state? I am not sure I can appreciate this angle, since I think it is farfetched that the swap mapping can somehow be more resistant to attack than the filesystem mappings in the same running kernel.
Are people concerned about regular swap state being left on disk during a non-hibernated shutdown? If so, I would suggest that the swap crypto should not be conflated with the hibernation crypto. Add an ephemeral cipher to swap if you must, but use framing/metadata to reliably distinguish the ephemeral swap "noise" image from a valid hibernation image. I'm OK saying that hibernate must write an entire image and not assuming that regular swapping can opportunistically prepare any hibernation state prior to a hibernation event actually commencing.
While writing all this, I have thought up another possible angle. Maybe this is the actual Fedora issue? I can see that control of an offline hibernation image means control of a future running system image, and this might violate some secure boot agenda? I.e. I can tinker with the hibernated state to introduce a "hacked kernel" and ask the system to restart with that. I can see why secure boot might prevent return from hibernation. This requires some integrity-protection chain to enable the trusted bootloader and kernel to verify a hibernation image before opting to load and restart it. I can see how a variation on your "sealed state" approach could address this. But note, it only requires integrity protection and does not actually need another layer of confidentiality protection.