1. Reimplementing an existing cryptographic primitive, such as SHA-256.
2. Inventing a new cryptographic primitive, with a reduction to existing cryptographic assumptions, and implementing it. A recent example is SPHINCS-256, which was proven secure in the random oracle model.
3. Postulating a new cryptographic hardness assumption, inventing a new cryptographic primitive based on it, and implementing it. Recent examples are IOTA's Curl hash function and StarkWare's Jarvis cipher.
#1 is risky, but at least the risk can be mitigated by having qualified peers review the implementation. #2 is riskier, but still, it can be mitigated by having qualified peers review the proof. #3 seems far more dangerous, since it involves conjecture.
What the Tupelo team is doing is like #2 -- risky, yes, but not comparable to #3.
Those who actually make their own encryption libraries know their stuff, and have been in the space for years.
You should never, ever, roll your own encryption.
If it's a requirement, then change your damn requirements, because just like consensus; it is not easy to get right, and the pros make mistakes.