This is more like your insurer following you around and evaluating your driving skills.

And yes black boxes are a thing but a) are opt-in and b) universally reviled.

For some tasks, the static scheduling you described is appropriate (although you could still consider it a form of concurrency), but it needs complete cooperation between tasks and an overall design.

But as soon as you need some sort of fairness, responsiveness, and tasks that are not designed for full cooperation if not outright hostile, you need not only concurrency, but full preemption.

And even with deterministic scheduling, concurrency might be dictated by external stimuli (for example request arrival) that are not deterministic.

It is very important in interactive or realtime systems.

preemptive concurrency is almost as old as interactive computers. Until fairly recently, most computers were single core, but you wouldn't have wanted to use a cooperatively scheduled OS [1], especially on a multiuser machine.

[1] yes, in the '80s some popular microcomputer OSs were single threaded (DOS) or cooperatively scheduled (classic macos and 16bit windows), but even then preemptive OSs were available (amigados).

Interestingly, posix realtime FIFO scheduling doesn't preempt even on kernel thread based implementations, so one reading of the standard would require yield on this case. But that can actually be potentially catastrophic as FIFO scheduling is expected to be deterministic. But realtime scheduling is already beyond the standard: I doubt gcc and clang will do the transformation by default.

In practice the equivalence is necessary to make some obscure corner of the memory model work and prevent some undesirable optimizations; I expect that in practice the compilers, if they implement this at all, will provide an opt-in flag, but they will optimize as-if the call was there.