That makes sense in terms of no standard libraries. But how about design patterns for common scenarios, eg. securing REST apis, User authentication/Login/Signup, Payment information handling etc, all in one place.
Does it become less secure if everyone follows standard design patterns?
No, of course it does not become less secure. In the worst case, slapping some crypto onto a system would have no effect at all; it is hard to see how it could make things worse, other than to give people a false sense of security.
An example is Hushmail. Your mail is signed, it is encrypted, you're using the tried-and-true PGP...and the DEA can walk into court with a pile of DVDs full of the plaintext of some defendant's email. Hushmail is, at best, only marginally more secure than GMail.
So while we might come up with good practices for using cryptography, it is inevitable that organizational practices will render the cryptography pointless. Solutions need to be tailored to the specific needs of an organization or a system. That is where the real problem lies: we do not have something like SQL for cryptography. We do not have a good way to specify organization needs and design (or even verify the security of) a cryptosystem that meets those needs.
Does it become less secure if everyone follows standard design patterns?