I recently spent something like two days performance-tuning someone else's code. This included a handful of SQL statements and visualization stuff in C#. Several things had gone wrong, some missing database indices here, suboptimal SQL queries there, and a lack of understanding for what happens on under the hood of certain .NET framework methods. Performance penalties which might not hurt on a resultset of some hundred rows (or even occur unnoticed when no one pay attention), will cause disaster once database tables grow to some hundreds of thousands or millions of rows. And you don't want your customer to find that out in a year or two. Your goal is to avoid things like that from happening from the very beginning on.
In larger projects there should be at least one person solely responsible for testing and improving performance. Those are the guys who will rap the developers' knuckles when they chose wrong approaches. They normally have their test automation tools along with a set of load and stress cases at their disposal. And they know how to tune performance.
Small to medium size projects often don't carry that kind of luxury. Anyway, raising the developers' grasp for runtime issues is important in either case.
