Salsa20 is an ECRYPT eSTREAM Phase 4 cipher, tied with Rabbit for the #1 software stream cipher. eSTREAM is to stream ciphers what what the AES competition was to block ciphers. The eSTREAM committee included Bart Preneel, Vincent Rijmen, and Matt Robshaw. If the thing you're reacting to is that NaCl doesn't use AES, note that the peer review Salsa20 got was substantial.

Elliptic Curve Diffie-Hellman (ECDH) isn't "all but unreviewed". ECDH is a NIST standard. Curve25519 is just an implementation of ECDH over a set of parameters that admits to especially fast implementation.

The hash function in NaCl is SHA-512.

Poly1305 isn't a hash function. It's a polynomial MAC, similar to what's used in the NIST standard GCM. If that's what you were referring to as "the hash function that isn't even in the SHA-2 competition", note that none of the NIST authenticated encryption modes use (comparatively slow) generic hash function constructions like HMAC, and none of the MAC functions they do use (OMAC, CBC-MAC, GCM's poly eval) have been entered, like apples, into SHA-2's orange competition.

I don't know who you think Daniel J. Bernstein is, but the short answer is: extremely reputable cryptographic researcher.

The sad thing is, your core argument --- that it would be "safer" to use NaCl using the NIST curves and AES --- is valid, and would have been informative if you hadn't chosen to phrase it in such a dismissive way. As it stands, I'm left thinking you don't know what you're talking about and just stumbled on this critique, particularly as your professional background contains basically no crypto or security.

Either way, you are almost certainly better off using NaCl with DJB's bespoke algorithms than you are trying to patch AES, HMAC-256, and RSA together using OpenSSL. We break actual peer-reviewed cryptographic algorithms in the field during penetration tests basically never. We break homebrew AES and RSA constructions about once a month.