Because many people would say "Why bother?", from both ends of the argument. Someone who is naively rolling their own crypto would say "Why should I waste time double-crypting everything and implementing wrappers when I'm investing all this time in my own super-cool crypto which no one can crack because I'm so awesome?" and someone else who is recommended against it would say "Why bother spending all that time duplicating work that's already been done for you by experts when your custom layer is just going to get compromised anyway?"

So in short, for practical purposes, it's just not efficient, in either programming time or performance time. If you want to double-wrap, as it were, more power to you, but be aware of the costs.

If you are going to double-wrap, it'd be best to wrap the payload in your custom package first and then standard second on the outside, so someone has to overcome the first barrier before they can find anything out about the custom/second barrier. That's a deterrent that would probably require man-time and sufficient interest if indeed the NSA can automatically decrypt current standard crypto.

I also think there's a little bit of confusion here. When people say "Don't implement custom crypto", they usually mean "Don't implement your own crypto library to implement common standards and algorithms". Most people don't think they can create crypto that rivals the publicly-used cryptographic algorithms out there, so the issue is usually about whether that person should implement AES directly or through GnuTLS, etc. If the NSA has holes in AES and you implement it correctly, you haven't really accomplished anything. This is probably what you've been talking about, but I want to make sure that point is clear for any other readers.

And just for a counterpoint, I remember an exchange on here by tpatceckd and cpercival many years ago where Thomas congratulated Colin on being one of the few to actually correctly implement industrial-grade crypto standards without using one of the major libraries. If either of them are reading and I'm misremembering, feel free to correct me, but the issue is less about stifling things or leaving backdoors for the powerful than it is about preventing the types of subtle but critically damaging bugs that run rampant through basically any code that hasn't been extensively battle-tested and matured in the crucible for years.

Since encountering cryptography in the wild is a signal that you may be stumbling upon something high-value, it's definitely not the kind of thing that you normally want to be taking chances with. That risk profile that makes a tried-and-true-but-possibly-compromised-by-the-most-technically-advanced-people-on-earth implementation better than a I-just-rolled-this-at-home-so-I-know-the-NSA-hasn't-hidden-any-backdoors-in-it-but-probably-someone-will-crack-it-after-three-days implementation.