You're implying (with unnecessary snark) that:

1. Development machines should be configured identically to production machines. (Do you install a GUI and development tools on your production servers?) Occasional differences in behavior between development/production are par for the course, and is why staging environments are commonly used.

2. The mitigations affect the execution result of code likely to be developed/executed at a typical software shop. AFAIU the attacks are timing-based, and won't affect valid code that's not specifically looking to exploit them.

try convincing a corp sec dept in large org to sign off on disabling anywhere.

Not everyone has ‘production’. A mathematician running experiments only locally, for example.

Surely that objection applies to being able to turn off mitigation at all, not to whether the invocation that does so is short or (as currently) long?

:p yes, there will be some of that around.

What's an example of typical application code that will behave differently with the mitigations on or off?

> What's an example of typical application code that will behave differently with the mitigations on or off?

Pretty much any application where there is limited execution time budget. If it takes too long it's considered broken, unusable, undesirable etc. Any realtime-ish stuff.

Ad bidding, video processing, audio processing / messaging, industrial control systems, robotics, general signal processing, logging systems that will now be overwhelmed and drop messages, databases that will experience timeouts and retries, scientific computations that will now take weeks more to run and potentially screw up other projects.

But hey it's a great time for Intel. Hey, psst, over here, I got a faster later gen CPU for you, for an easy price of $999.99 to bring you performance back to where it was last week.

Certainly the speed of it's execution. That could be difference enough to be concerning when shifting from dev to prod.