fool

It depends on what you mean by "secure". I'm going to assume that your threat model is "I want to minimize the damage caused by any generic malware". If you would like tips on some other threat model, I would be happy to assist you.

Generally, I would recommend fedora secureblue or silverblue. It works very well "out of the box", doesn't require much maintenance, and it has relatively good security defaults.

I wouldn't call NIXos inherently "secure", because it doesn't have nearly as many security benefits compared to more security-focused distros. Immutability doesn't really help much in this context because all it's doing is making your root read-only. In most cases, an attacker getting access to your home directory is just as bad as them having root access. Security aside, if NIXos suits your other needs then I encourage you to keep using it.

Qubes is probably overkill. I would only recommend using it if your threat model depends on it. It offers very good sandboxing/compartmentalization, but it can be tricky to use and is resource-intensive. Personally, I don't think it has the best "out of the box experience" and most of its benefits can be replicated (with much effort) on a distro like gentoo or arch.

Gentoo and Arch have the highest potential to become the "most secure" because they are the most customizable but they require a lot more maintenance since you essentially have to learn how to build your system from the ground up.

In the end, I don't think the distro matters too much because as long as you can tweak the distro to fit your needs (or threat model), you will eventually end up with your own perfect mix of usability and security. You can start hardening your system by: configuring the firewall (I recommend ufw), proper sandboxing (I recommend using flatpaks or writing your own bubblewrap scripts), and maybe running untrusted processes in a virtual machine (I recommend qemu/virt-manager). For more advanced security, I would highly recommend looking into Mandatory Access Control (Fedora enables SELinux by default but you can tailor the reference policy to be VERY strict).

Once again, If you have anything more specific in mind in regards to security, I'll be happy to elaborate :D

It should work almost exactly the same as hard drive encryption. In my experience, the read/write overhead from encryption is negligible. Encryption shouldn't affect wear-leveling, and it's still possible to TRIM the drive to discard any unused blocks (although TRIM may leak some filesystem metadata).

If you want to ensure any previous unencrypted is erased on the SSD, consider formatting and trimming it before encryption (using something like blkdiscard). Hibernation should still work, it will just prompt you for your encryption passphrase then resume your session. I'm not sure about any lost functionality, but it's been seamless for me.

Depending on your threat model, keep in mind that full disk encryption typically leaves the boot partition (usually containing the kernel, initrd, and bootloader) unencrypted since it's needed to boot the system. This can leave you susceptible to evil maid attacks or modifications from another operating system (if dual booting). For most people though I assume this shouldn't be an issue.