The last comment in that link describes well what I've experienced.
Many developer have to deal either with large, legacy systems that have been around for a decade or more (and written by teams naive to such attack vectors), or newer systems with minimal deadlines that barely allow for a functioning system, let alone one with solid encryption. In either case, the result is the bare minimum of encryption or other security measures. Even when the developers push back and say that more security is needed, they're often steamrolled by management.
Security in general takes time and resources, and it's a proactive measure. Management typically runs reactively. Trying to rationalize a proactive measure with a reactive person doesn't generally work out too well. In their eyes, you're spending resources to prevent something that may or may not actually happen ("it hasn't happened yet..."). That, to them, is nothing but expense with no "actual" benefit. Unfortunately, that leaves most developers to stand back and let them learn the hard way, even when that means the customers (or other employees) are going to pay the larger price.