You DO have a knack for hitting the "sweet spot" with me, Steve. 😀
I've found that the causes of writing high-resource-usage code can be boiled down to 3 things.
1. Demanding schedule which leaves no time to check for alternative methods that may lead to less resource usage.
2. The "just get if off my plate as quickly as possible" syndrome exhibited by many developers even when not under schedule pressure.
3. Lack of knowledge and data to test with.
The latter reason (#3) is inexcusable considering how easily correctable it is. You're being paid to do a job and to do it well. A lack of knowledge in the area(s) that are required to actually do your job is your fault. Please, no whining about the company not paying for your education. Most people just starting out in the job market didn't have a company pay for their education. If the company you work for won't pay for education, suck it up and get your own education. A great education in SQL Server is relatively inexpensive to obtain. A cheap desktop computer, a $60 USD (including shipping) copy of the Developer's Edition of SQL Server, and a $60 USD book or two are most of what you need. If you want to officially document your education, taking an MS Certification test or two will only set you back a couple of hundred bucks. The rest is simply taking the time to study and practice your trade on your own. Additionally, reading about and solving problems on forums will give you a world of practical problems not available in any book. Studying other people's solutions to these real world problems will give you an incredible education not easily duplicated and usually not available in any book.
The justification of "having a life", especially if you have kids, is a very strong one. Just remember, when your kids get hungry, they can't eat you. You'll need to have a good job to pay for their food and maybe even their education so they won't have to work as hard as you do. 😉
Part of the lack of knowledge are the skills necessary to make large quantities of test data especially when shrink-wrapped tools to do so aren't available. Here's an opportunity to suck it up and learn something on you own. Please see the following two articles. Whether you read and learn anything from them or not, you can no longer say that a lack of data is the reason you didn't test for scalability and resource usage.
As to the first reason (#1), you managers need to learn to make better schedules. You need to stop over promising in a vain attempt to look good, learn to properly estimate jobs, and learn the lesson that every manager should learn. That is "If you want it real bad, that's the way you'll normally get it". If a bad schedule comes to you "from the top", you need to grow some hair and push back a little because delivering a bad product to the customer is much worse than missing a deadline. And to be sure, delivering a bad product to the customer is the fault of only one person… yours.
Last but certainly not least, you need to learn how to hire good people and pay them well enough to keep them. Treat them with the respect they've earned. Enable your team. Don't try to lead them. Rather, set an example. Follow those suggestions and they'll make you look good without you even trying.
As to the second reason (#2), you people need have a serious change of attitude or find a different career. The only good thing about you is that your continued actions guarantee that people who are in the business of cleaning up performance challenged code will have a lifetime of high paying work.