IMO, the amnesty cutoff date should be 2003. And not just for SQL Injection - there's all kinds of vulnerabilities in code that have been exposed (another example that should have died a long time ago is cross-site scripting), methods to do it safely and properly have been implemented, and the dang developers are either completely incompetent or too lazy to do it right. Fire them all, and get competent programmers that will actually work with the DBA to do it correctly.

But it boils down to the companies. If you are going to have an emphasis on hiring the cheapest person, you get what you pay for. If you aren't going to have regular training on how to do things correctly (including newly discovered things outside of your company), you deserve what's coming to you. If you sweep it under the rug... shame on you. Where is the code review for this code that's being written with all of these vulnerabilities? That usually comes down to a resource availability to do it - something that the company controls and not the developer. There are programs that will test your code for vulnerabilities - not using these is a company decision. This is a topic that you just can't take a shortcut with.

From a developer standpoint, there's no excuse for implementing such shoddy code.

From a business standpoint, there's no excuse for allowing it. And the onus is on the business to ensure that it is done properly. If your business has an environment where this is allowed to persist, there's no incentive to ever change from "we've always done it this way". And your developers never will.

And if your business sells this product, your business should be held liable for every individual instance of these security preventative measures not being followed, with a minimum fine a $500,000 (USD) per occurrance. Unfortunately, businesses usually won't change until it becomes less expensive to do it right the first time, and the only way this will happen is by steep fines when they don't.