Public key is always going to be trickier to keep secure as they all rely on assumptions, and that will lead to a never ending "arms race".
Well, careful, symmetric ciphers depend on the existence of one way functions. If P happened to practically equal NP, then one way functions couldn't exist and I could solve for the symmetric keys that turns your ciphertext into ascii (there is probably only one).
NOT. BLOODLY. LIKELY. (kinda sadly, there would be a lot of other befits to such a world)
It's possible to construct public key signature systems that depend only on the existence of one way functions. (Lamport!)
The soundness assumptions in error correcting code crypto-systems are also generally pretty solid (well, we keep breaking them trying to make their overheads tolerable…) (solving for random linear codes is NP-HARD ... the only question is can the attacker turn your public key back into an easy linear code)
Considering that for encrypted messages overhead is mostly immaterial I'm surprised that no one has created a stone soup protocol that just takes "one from each column":
NIST-521 bit ECDH, just in case the NSA made it stronger
1024 bit ECDH with parameters selected the best known public art techniques (e.g. like the brainpool curves)
Supersingular isogenies key agreement
Wrapped up inside an error correcting code public key encryption
And that encrypted with a symmetric key which is from the recipient, a starter one is in the public key.. though thats not very useful.
Feed it to a pair of orthogonal strong KDFs which then feed separate passes of multiple standard ciphers (unrelated keys) in some long block modes.
Then inside the encrypted messages you send symmetric keys generated using H(random, data_thats_part_of_your_private_key) which your receiver will save and use as an additional key in your KDFs in messages they send to you in the future (perhaps up to N of them with octave spacing, so a spy that can break the public key stuff will get locked out with high probability if they miss any of your messages).
Perhaps then the whole message gets thrown through a gnarly unkeyed cryptographic permutation and coded up with a RS code and you replace it with the non-systematic outputs and, at your option send, the message in as many parts as you like over different communications channels... so an attacker who can't snoop all of them learns almost nothing about the whole message.
Care would need to be taken to avoid interactions that hurt security.. but for encrypted messages.. who gives a crap if there is 50K of overhead and it takes a half second to decrypt? There are plenty of applications where thats totally unacceptable, like Bitcoin... but also plenty where it is.
... wait. what board is this?? woah .. way offtopic.