Thing is that the dev servers of the past was never equal in setup of the prod servers, difference in software versions, failovers, proxies, crons, backups etc, that was just a lie that was told.
In my opinion is is much better to develop a cross platform/environment product that can work everywhere and the key to that is to avoid assumptions about where the product is executing. In the long run, this makes your software much more flexible.
There is a significant difference between "works everywhere" and "works everywhere efficiently". For the former you can get away with just writing portable code. For the latter you basically have to benchmark everywhere. Performance is a hell of a leaky abstraction.
Yes, that is why it is futile to try to have an exact copy of the production server because the smallest difference will ruin your performance profiling, to be absolutely sure you have to do the profiling on the production server itself.
Usually every developer has their own login user on the development machine, but that is enough to skew performance profiling, because usernames populates environment variables & that will change memory layout of any program that the shell executes.
If memory layout changes due to environment variables significantly changes performance characteristics then it looks like an opportunity to optimize this aspect of loading a binary. I assume cache alignment is in play here.
It's great that they can average out the random effect of layout, but what I meant by optimization opportunity is to deliberately aim for the "good" memory layouts. Something like fixing the alignment of the stack on program entry point or marking specific functions as "stack aligned".
In my opinion is is much better to develop a cross platform/environment product that can work everywhere and the key to that is to avoid assumptions about where the product is executing. In the long run, this makes your software much more flexible.