The point of criticism is to help people improve. By effectively saying, "You're not cut out for crypto, don't even bother," you do a disservice to others and contribute negativity that HN doesn't need.
"This is just a proof of concept. It's not secure. It's just a learning exercise. Don't use it for anything other than learning."
I haven't looked at this project, so maybe it does have those warnings.
The problem is not creating and releasing such applications; the problem is overclaiming their security, or putting early confidence in them.
Crypto is hard, we get it. Beginners and non-experts are going to mess it up, we get it. Even experts almost always mess it up, we get it.
Still, a good programmer of crypto software (or even just, "wise user of battle-tested crypto libraries in the proper ways") will almost always start out as a bad programmer of crypto software... who got started, and learned by failing.
To borrow an aphorism from other project/product wisdom: if your first version's crypto isn't obviously and embarassingly broken, you waited too long to release.
Broken cryptography can cause loss of money, infrastructure, and life. Imagine if a group of dissidents where to start using this program, the crypto implementation was subtly wrong somewhere, and they were disappeared by their government early one morning. Imagine if some transmitted a password through what they thought was a secure chat, and that password led to an industrial control system for, say, a subway, water treatment plant, foundry furnace, or explosive chemical storage tank. Software doesn't just move Tweets. There are massive, hot, high-voltage, fast-moving objects controlled by software also. Letting people believe information is safe when it isn't can have very real consequences.
Unless it is obviously written all over your software that "THIS IS A TOY AND YOU SHOULD NOT EXPECT IT TO ACTUALLY KEEP ANYTHING SECRET," your obviously and embarrassingly broken crypto (to a crypto expert) might look just fine to a nontechnical user with dollars and/or lives riding on your product.
Not, "stop releasing hobby projects".
The reckless non-technical user who grabs any project that mentions a slight sheen of crypto-sparkles, and then trusts that software with their life or savings, is doomed anyway. The existence of one more hobby project with amateurish crypto isn't going to kill or bankrupt him twice over.
When you've done all of that, you'll know that you are abysmally incompetent at cryptography. When you know that, you can start learning how to become good at cryptography. Some people divide learning in four steps: unconscious incompetence (you don't know that you're bad), conscious incompetence, conscious competence and unconscious competence.
Even when you're competent, you will make mistakes, because cryptography is very hard. We've seen how MD5 is now broken, yet still people use it as message authentication ciphers even when it's trivial to perform a length extension attack. But MD5 wasn't always broken. I'm sure it was designed by competent people, but they can't foresee all flaws.
That is why someone who is incompetent at cryptography should not do it.
Probably when you understand "Applied Cryptography", front to back, maths included, then you can think about writing cryptographic software.
Or win a fist fight with Schneier.