Yes, there is a reason to discourage those people.
In between the time that a cryptographically illiterate developer releases their MVP 1.0 version and the time that it's discovered that their cryptography is fundamentally flawed --- a window of time that can stretch on for years --- actual people will rely on the tool for their security, not realizing that serious adversaries are reading their messages.
Most new cryptosystems --- a cryptosystem being "anything that uses a cipher, including when the cipher is simply AES --- are terribly broken.
Search for [decryptocat] for an extremely good example of what I'm talking about.
Developers who are new to cryptography that want to learn more about it and eventually use it in their own systems should start by learning how to exploit broken cryptography. If you can't exploit an RSA padding oracle, you shouldn't be designing systems that use public key cryptography. If you can't exploit a CTR nonce stutter, you shouldn't be using block crypto.
Developers who don't want to learn cryptography should work on improving the UX (UI and workflow) of existing cryptosystems. PGP could sure use some help, but even if you don't want to help with PGP, there's a huge green field of work to be done on browser TLS trust and CA user interface. Just as one example.
My point is that this attitude of "only people who have proven themselves as cryptography geniuses may dare to think about thinking about cryptographic protocols" also discourages the potential UX/UI/workflow/etc. programmers from participating, since it gives the impression that their contributions will never be "good enough" to be accepted. It also discourages potential developers of the crypto algorithms and protocols themselves from participating, even if they have gone through the (in your opinion) requisite experience of learning how to break existing cryptosystems, because of the fear that they'll just be burned at the stake by the rabid likes of Hacker News and Slashdot for daring to suggest anything new (these are the sorts of cryptographic programmers I'm talking about, not some "badass rockstar ninja" Macbook-toting YCombinator-funded Ruby.js hipsters manufactured in the heart of Silicon Valley like you seem to be implying).
This results in things like GnuPG being considered hard to use. This results in things like GnuPG struggling along with a single core developer and barely enough funding to support that developer (even now). This results in things like OpenSSL being horribly undermaintained, to the point where nasty bugs like Heartbleed are allowed to exist longer than they should because there is an insufficient quantity of eyeballs to find them and squish them. It doesn't take a rocket surgeon or a cryptographic guru to see that this is nothing but an awful situation for pretty much everyone involved.
i think any 3rd party distributed crypto is only useful against weaker adversaries (weaker than the person doing the distributing). For p2p crypto designed and agreed to by the two parties, there are lots of options, starting with a 1-time pad, CTR mode hash based ciphers, etc...
In between the time that a cryptographically illiterate developer releases their MVP 1.0 version and the time that it's discovered that their cryptography is fundamentally flawed --- a window of time that can stretch on for years --- actual people will rely on the tool for their security, not realizing that serious adversaries are reading their messages.
Most new cryptosystems --- a cryptosystem being "anything that uses a cipher, including when the cipher is simply AES --- are terribly broken.
Search for [decryptocat] for an extremely good example of what I'm talking about.
Developers who are new to cryptography that want to learn more about it and eventually use it in their own systems should start by learning how to exploit broken cryptography. If you can't exploit an RSA padding oracle, you shouldn't be designing systems that use public key cryptography. If you can't exploit a CTR nonce stutter, you shouldn't be using block crypto.
Developers who don't want to learn cryptography should work on improving the UX (UI and workflow) of existing cryptosystems. PGP could sure use some help, but even if you don't want to help with PGP, there's a huge green field of work to be done on browser TLS trust and CA user interface. Just as one example.