No it doesn't. Development time is a one off (for a given feature set). Usage is recurring, so savings in running time catch up and eventually dwarf development time.
But I don't think this calculation makes much sense in the first place. It's simply not that linear and depends on many other things, for instance whether it's a throughput or response time problem, the relative value being the first to market versus being the best, etc.
Time running the app is both irrelevant compared to the time it takes to develop it. Also, as long as the app offers the answer quickly enough from the user's perspective, fast enough is fast enough and being able to iterate twice as fast as your competition is the ultimate advantage.
Making it fast enough from a user's perspective comes at a cost though (where it is possible at all). If you have many users and you have to pay that price for each one, it becomes very expensive.
All I'm saying is that at some point it becomes way more expensive than paying developers to optimize or rewrite in a faster language, which is exactly why Google and Facebook are doing so much work in C++, not exactly a language known for developer productivity.
And obviously there are many places where you can't scale your way out of a response time or battery usage issue because you're not the one buying the machine.
So I totally disagree with your assumption that developer productivity always trumps runtime efficiency. It is also my experience that the productivity advantages usually ascribed to some (mostly dynamic) languages is way overblown. But that's another debate.
Even if I have to rebuild part (or all) of the application in some future moment, the initial productivity boost is worth a lot. Rebuilding a program that is already running is usually far less painful than building a fast one from scratch. At least the developers will have a test suite they can use to check whether their version is correct. And how much faster.
I agree there are cases where only the leanest and meanest code will do, but my point is that those cases are very rare.
