Yep, more that actually being able to turn interrupts off is a barrier to doing real time work on desktop OS's, for example. Even if you can disable them globally (I think on the Pi you can with some low level C), but stuff goes wonky quickly e.g. if the WiFi soc doesn't get serviced.

It's a good lesson to play with polling versus interrupts on a micro. Susprising just how many cycles it takes to jump into the ISR.

This! Automotive hard real time is polling based.

I think most things are trending that direction, even in soft/non real-time. How fast can an interrupt respond these days anyway, a dozen microseconds?

Nanoseconds if you can respond inside the interrupt handler ('top half' in Linux.) Microseconds to milliseconds with significant variability if you need to be scheduled ('bottom half'.)

And that only if your codepath is deterministic. Linux can do pretty funny stuff at times.

I've run a plasma cutter under Linux on a run-of-the-mill VIA SBC, it was actually pretty easy: just make a program setuid root, use that to disable interrupts after you've read all your data in and then just go wild on polled and precision timed IO until you're done. Re-enable interrupts and return as if nothing ever happened.