I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?
As far as the Amiga task system works, it should. A higher priority task will always pre-empt a lower priority task. Thus, whenever your "real time" (something like that does not exist on the Amiga) application requires the CPU, and it has a higher priority than the background job, it gets the CPU.
You might find out that GCC is loading some files from the disk and this is delegated by the OS to tasks running at higher priority than your task. Suddenly your real time task is blocked by the OS serving low priority tasks.
It's not quite as bad. The FFS has a higher priority, yes, but it does not do much. It just prepares a couple of buffer pointers and then gives control back to the hardware abstraction level aka "device". Here, again the game is the same: If you have hardware that is smart enough, the device will only initiate a DMA, and hence give control back to the foreground job as long as the transfer is running. CPU time is not "burned" while waiting for the I/O.
If you are have a sorry "PIO-only" host adapter, you have a problem, though, because somehow somewhere the CPU needs to take the time from to transport the data from the disk to the RAM. That, then, of course, can really steal important time and make your day, and the device has no knowledge about which I/O it should initiate first as the origin of the request is lost. But that's not really the fault of the AmigaOs, but rather of the hardware requiring full CPU attention for I/O. It does not happen for DMA-based host adapters.
Nothing in the device, however, and nothing in the filing system - at least in the Amiga FFS - will block. The FFS is itself multithreaded (in some sense), so it can take multiple requests at once and schedule them to the device independently. I'm not so sure about these alternative "professional" or "smart" filing systems whether they can really do that. FFS can...
To me it seems that if you dont raise your own priority over OS tasks you dont get served as expected. It doesnt matter how fast your system is. As long as you are running at priority lower than 10 the scheduler cant guarantee you fair share to the CPU.
Probably task priorities do not work as you expect them to work. The priority does not define a proportionality factor for the time slice of CPU time a task gets. It is rather an absolute number of which task can pre-empt which other task. As long as there is a higher priority task requiring the CPU, all lower tasks do not get the CPU at all. That is, if there is a task running at priority one, everything at priority zero and below gets *no* time at all. (And not just "less time". I mean really: NOTHING). Thus, if you have a foreground job at prio=1 and a background compiler job at prio=0, then the compiler does not run at all. As simple as that. Whether that's good or bad is another rmatter, but this is how exec works.