I agree that the peak is pulling away from the average, and most of us want the average performance of applications to lift. We have to throw aside facile "Good Enoughism" and genuinely respect the time of our users.
Where I differ a bit from your take: Languages and platforms that target high performance are providing application developers an elevated performance ceiling that allows them the luxury to use CPU capacity as they see fit. Application developers using high-performance platforms may then elect to make their application high-performance as well, yielding a truly high-performance final product, or they may elect to be spendthrifts with CPU time, yielding something middling on performance. And yes, a truly wasteful developer can indeed make even a high-performance platform yield something low-performance.
What benchmarks and the resulting friendly competitiveness help us avoid is a different and worse scenario. When we select a language or platform with a very low performance ceiling, application developers continuously struggle for performance wins. The high water mark for performance starts out low, as illustrated by how much time is spent in order to accomplish trivial tasks (e.g., displaying "hello world"). Then further CPU capacity is lost as we add functionality, as more cycles are wasted with each additional call to the framework's or platform's libraries. When we select a low-performance platform, we have eliminated even the possibility of yielding a high-performance final product. And that, in my opinion, illustrates the underlying problem: not considering performance at key junctures in your product's definition, such as when selecting platform and framework, has an unshakeable performance impact on your application, thereby pulling the average downward, keeping those peaks as exceptions rather than the rule.
Where I differ a bit from your take: Languages and platforms that target high performance are providing application developers an elevated performance ceiling that allows them the luxury to use CPU capacity as they see fit. Application developers using high-performance platforms may then elect to make their application high-performance as well, yielding a truly high-performance final product, or they may elect to be spendthrifts with CPU time, yielding something middling on performance. And yes, a truly wasteful developer can indeed make even a high-performance platform yield something low-performance.
What benchmarks and the resulting friendly competitiveness help us avoid is a different and worse scenario. When we select a language or platform with a very low performance ceiling, application developers continuously struggle for performance wins. The high water mark for performance starts out low, as illustrated by how much time is spent in order to accomplish trivial tasks (e.g., displaying "hello world"). Then further CPU capacity is lost as we add functionality, as more cycles are wasted with each additional call to the framework's or platform's libraries. When we select a low-performance platform, we have eliminated even the possibility of yielding a high-performance final product. And that, in my opinion, illustrates the underlying problem: not considering performance at key junctures in your product's definition, such as when selecting platform and framework, has an unshakeable performance impact on your application, thereby pulling the average downward, keeping those peaks as exceptions rather than the rule.