We can get into the weeds about which specific cryptographic primitives are fine in isolation, but that misses the point — the ones that were fine 5-10 years ago are still more or less fine — the problems for developers and end-users generally stem from accidental misuse of cryptographic primitives in designing systems incorporating cryptographic primitives as a component. Sure, don't use DES, DSA, or MD5/SHA1; strong primitives are only necessary, not sufficient.
The appeal of libsodium is that it is (or was) mostly an easy to consume NaCl. Correct me if I'm wrong, but I don't think libhydrogen is related to NaCl or the NaCl authors.
See my original comment about attack surface. Given the correct set of circumstances, transmitting the IV in the clear with CBC could possibly open you up to chosen ciphertext/plaintext attacks. And you better be doing encrypt-then-prepend-IV-then-MAC with CBC. Just a lot of gotchas that may or may not be relevant, depending on your environment.
At minimum, for asymmetric, at the time of the writing:
* ECDSA with secp-256 or ed25519 curves
* RSA >= 2048 bits. Performance takes a steep dive at 4096bits unfortunately
What people don't understand is that your implementation needs to be selected against your attack surface. If your attack surface includes hardening against side channels, your implementation selection needs to take that into account.
For new designs: basically just use libsodium.
For SSH: Ed25519 or 2048 bit RSA.
We can get into the weeds about which specific cryptographic primitives are fine in isolation, but that misses the point — the ones that were fine 5-10 years ago are still more or less fine — the problems for developers and end-users generally stem from accidental misuse of cryptographic primitives in designing systems incorporating cryptographic primitives as a component. Sure, don't use DES, DSA, or MD5/SHA1; strong primitives are only necessary, not sufficient.