The opposite turns out to be true in practice. People have the choice of using a simple crypto library interface (like BouncyCastle PGP) or "really getting to understand" AES, and so end up fielding software with vulnerabilities PGP addressed in the '90s.

A pithier way to say the same thing is, "you're right, except for the words 'without understanding it'".

This is true, but most programmers don't and won't ever get a deep understanding of crypto. For that large majority, it makes complete sense to ask "What do the people who do understand crypto use in a case like this?" and use that.

That kind of copying is clearly inferior to either gaining the knowledge to make an informed decision or hiring an expert to do it for you, but for most projects that need crypto neither one of those is practical. So, copying the experts is the best practical approach in most cases.

It depends what level you are using it on. If you are writing crypto libraries on your own then sure you are at significant risk of screwing it up, but a good crypto library should have good defaults that will provide proper security.

Expecting every programmer who needs to build an application that stores passwords or personal information etc to have a rigorous mathematical understanding of crypto (this probably means having a PhD or similar in the subject) is just plain unrealistic.

It's sort of akin to suggesting you shouldn't allow a mechanic to change the brakes on your car without them having a detailed understanding physics.

I can use a microwave without any understanding of its functioning, or I can try to understand electromagnetism well enough to build my own. I know which method I'd trust not to render me sterile.