What I find is that programmers I've worked with who have been the most preoccupied with performance always seems to have focused their optimizations in the least valuable areas. It's as if performance mania is directly correlated with a kind of architecture blindness.
Mid-level developers haven't had a lot of those problems yet, but they have read articles about them, and those articles usually do silly things to try to prove a point in a simplistic situation.
We had a developer that was obsessed with getting rid of jQuery for performance reasons, but repeatedly failed to recognize that the raw JS functions he wanted to use didn't work on IE and/or Safari, IIRC. Beyond that, we also supported Android 4.4's webview, and he didn't even have a way to test that. He ended up leaving the company for other reasons, but it was a constant battle to keep him in check with that stuff.
(It required compiling the Cordova app, and so long as you kept doing things the same way as the rest of the codebase, it almost always just worked. So we didn't require junior/mid-level devs to test it on every change. It did get tested eventually before the app got a new version, though.)
Yes, it does save a few function calls and instantiating a class - but that's not where the real bottleneck is. The proposed changes would require rewriting large amounts of code elsewhere, making the logic more verbose and complex.
It took some effort to convince the person that the trade-off isn't worth it. I tried to be diplomatic, but I'm afraid they took it personally that the pull request was declined.
I wish I could have proved my objection with some metrics - how many milliseconds were shaved off by the proposal, versus the increased "cyclomatic complexity", as a measurement of its detrimental effect on the code base.
Rather than rejecting outright, did you consider blocking the pull request and asking for benchmarks demonstrating that the optimization was worth the complexity increase? Maybe they would learn more from that process than from an explanation of why they are misguided.
The person put effort into the code, and I didn't feel that they were convinced of my argument against it. Their changes were more efficient logically, and I'm sure it would have saved a few milliseconds per call - whereas my claim of increased complexity was a more subjective judgement.
In the end, it came down to trust/authority - but they might have been more convinced, or felt better about the decision, if I could produce some numbers from my side, like a measurement of cyclomatic complexity based on static code analaysis.
Perhaps that could have justified the existing higher abstractions, to weigh their (almost negligible) performance cost against the value of reduced complexity - keeping the code base simpler to understand.