What's the logic of that though? Longer more descriptive names (self-documenting code) help readability, not hinder it.
Certainly time to enter code (which is increasingly going to be automated) should be the last consideration - if we're considering full software lifecycle then coding probably takes up some small single-digit percentage of the time we're interacting with the code.
Longer names are harder to read. Think about any math formula. Does energy=mass * math::powerf(speed_of_light, 2) read more fluently?
Context matters. Make sure the context is ways clear and code is written there where it belongs. Then names can be shorter while being readable.
I'm not sure that's a great example. Of course e = mc^2 is so iconic and well known that most people know it, and will probably even perceive it as a whole. Once you recognize it then no need to explain what e, m and c are.
However, most code is not that obvious, and in the real world you're probably not looking at one mystery line of code who's function becomes obvious by context - you are more likely looking at entire functions or blocks of code, maybe without comments, trying to figure out what is going on. Try inheriting 10K of mostly undocumented code, and then you'd probably be a lot more grateful that the original author used descriptive names and comments, even though he knew what it all meant when he wrote it.
We write code once, but read it many times, so longer names seems like a poor efficiency choice.