While I am definitely a proponent of keeping server software fairly current from a support standpoint, I was stuck by this comment in two ways.  First, the insight that most systems are not slow.  Secondly, that many systems are not going to benefit greatly.  I would further refine the first statement by pointing out that possibly most PARTS of most systems are not slow.  When assessing performance issues I think it is important to 'drill down' to identify the specific areas of code that are the real problem.  In my past experience, there were often certain pieces of code, certain stored procedures, that were problem areas due to being hastily or carelessly created and insufficiently tested for performance under production load.

It can be very difficult to justify the time needed to get into the detailed performance of code at this level, but it can yield huge results.  Either with commercial software or even by creating your own to collect performance data at these levels can often lead to the discovery of specific issues that can provide drastic performance increases without increasing hardware and software costs. 

First, you have to know exactly WHERE things are slow.  And then it may take lots of 'unit testing' to figure out exactly WHAT the problems are.  I have recently in another forum been involved in a discussion with a gentleman who was arguing vehemently against relational database in general by saying that they are horrible vehicles for transactional systems, so should not be used in 'enterprise' systems.  We need to be careful not to 'throw out the baby with the bath water'.  I suspect that if we are truly skilled at creating, evaluating and improving code there are valuable resources that can be recovered without just throwing money at problems.