It's extreme to demonstrate the point, but it's not contrived. Realtime deadlines are a completely normal requirement for the systems I work on. I have change reqs on my desk right now that specify a full reboot back to network responsiveness in <=300ms. That definitely changes how the system is designed.
It being extreme is what makes it contrived.
It's also a requirement programmers often overemphasise due to the McNamara fallacy.
Contrived does not mean unrealistic. I have seen many extreme requirements come down on short notice. Over time, the peter priciple guarantees that there will be a middle manager that miscommunicates an agenda they dont fully understand, then push an emergency change down the hierarchy.
No, but programmers fetishize speed. Customers usually value it far, far less than many programmers think.
Ive seen many a programmer gagging to rearchitect to speed up an app 2x or 3x when there are 9 other things a customer genuinely wants first and the programmer refuses to believe it.
Most recently it was on a RAG system where an extra 500ms would surely have been appreciated but the right answer mattered 100x more.
You missed the point of the example. The parent said any design that has to change with a single requirement shift is a bad design. So I gave a requirement that virtually any design would have to change to accommodate. It doesn't preclude the existence of other, more plausible requirements that shift designs. I even provided a real example of one, which you've ignored.