You've missed an important but subtle point. The article points out that the reason this was overlooked is not because Rails isn't profiled but because this behaviour is happening outside the standard rails profiling scope. That is a) why it's not a "relatively-straightforward bug fix", b) why it hadn't been caught already and c) why it is interesting. Actually I take that back, it is a relatively-straightforward bug fix. As with all the best bugs it's finding it that wasn't straightforward.

I think a similar thing happened about a year ago when people were profiling rails but not profiling memory usage. After they realised GC was impacting their performance they shifted their focus and improved things in that regard. The most recent "X line Y% speedup" article I read here took this even further and examined the impact of the size of stack vs. heap memory on GC times.

My particular favourite example of this is Steve Souders work showing how much your web app performance is affected by the end users browser and its wacky network and cache behaviour. He has claimed these factors can account for 80-90% of the end-users' waiting time. I know rails core have been working to fix these issues as they did a presentation about.

That sounds to me like a bunch of useful lessons to be learned from. Certainly more info than just "profiling good", more like non-holistic profiling can be misleading. Your response certainly doesn't cover this as you talk about "basic profiling", so what is outside the profiling you do? How would you know if it is affecting performance and to what degree?