While I totally agree with your main points, I suspect that a large part of the difference in productivity you describe is a result of your familiarity with Rails and its ecosystem. If you've done many projects in it, have established workflows you're comfortable with and know the framework inside and out, of course you are going to be more productive compared to using a less familiar technology.
Precisely. I respect Neya's point of view, but I interpret it as not specifically about Rails or other specific frameworks, but rather as a cautionary tale warning against needless branching out and exploration of other languages and frameworks. In other words, his experience seems to be a data point suggesting that you stick with what you know unless you have a strong need to diversify.
That said, one impetus of our TechEmpower framework benchmarks project was to encourage people to diversify their experience and consider performance as one metric in evaluating the broad spectrum of options. I personally feel that doing so is valuable for a variety of reasons, several of which others in this thread have pointed out.
We refer to a second dimension of "developer efficiency" that we can't measure as objectively as performance. We've had scores of conversations about proxies for developer efficiency, but haven't moved forward in earnest on any yet. That said, my strong belief is that developer efficiency is not inversely proportional to performance any more. Perhaps it was at some point in the past, but I don't feel that's the case now. I personally am just as productive, and in some cases moreso, in a modern language and framework, as I am in legacy frameworks and languages.
If it were possible to accurately and impartially measure developer efficiency and then scatter-plot developer efficiency and performance with a slope line, then yes, there may be a declining efficiency slope as performance increases. But I suspect there would be data points representing both high-efficiency + high-performance and low-efficiency + low-performance options.
It's important, but difficult, to isolate learning curve from long-term developer efficiency. But Neya is a useful counter-point to my argument, and if I might put words in his mouth, he is saying: don't trivialize the lost productivity due to the learning curve; it can be significant.
