It's pretty rare in software for it to define minimum performance. There's good reasons for this - software is interacting with intrinsicly messy things (like humans) and so performance outliers are a big factor.
It's pretty common in software for the worse case to be 10x the "hit your metric" case, and this isn't viewed as bad: the worst case happens rarely enough for the trade off to be worth it.
I am coming from the hardware world, through raw assembly, to C so my path is very much the assumption that if the microcontroller is going to control a feedback loop that stabilizes at 10MHz it will be guaranteed to do so.
But I suppose that I actually do that by overspecifying things nowadays since it's much too unpredictable as you say to predict how long things will take.
To me if you say you sample at 100kHz you sample at a minimum of 100kHz. Very very good to know that if I work with a firmware engineer that they won't hear the same thing as I mean if I say that it needs to hit a 100kHz sampling rate.
It would be very disappointing if they wrote a loop designed to average a 100kHz sampling rate with random jitter... (kidding mostly, I'd assume they would at least not do that).
I think you are missing something here.
Real Time systems aren't designed for high performance at all and instead they are designed for predictability.
You aren't aiming to "hit your metric", you are aiming to never, even go below it.
This is useful for something like old-style spinning hard drives where you had to calculate where to move the head of the disk within the time of the rotation. You have a instructions/second budget, and you know it will execute that.
On non-realtime hardware (and software) you know how many instructions/second it can do, but things like speculative execution of caching strategies or non-RTOS mean those instructions are not guaranteed at all.