Even worse, the current implementation of the graphics library runs into a busy-wait to let the blitter complete, it does not perform smart things such as sending the CPU into a Wait(), where it could allow another task to take over.
The decision to use such a (IMHO stupid) design was based on the slow 68K CPU. Back then, the overall overhead of the CPU reacting on a blitter interrupt, and managing and mainting such interrupts was higher than just to run into WaitBlit(), so the design remained as stupid as it is today. Whether this estimate still holds for faster CPUs, i.e. busy-wait vs. Wait(), is unclear to me and is something that is probably worth trying. At least it could free the (much faster) CPU doing something useful instead of wainting for the blitter.
I think it makes perfect sense. Busy wait in WaitBlit() is stealing CPU cycles only from other tasks and only if the blitter is still busy. Most of time the CPU had nothing useful to do anyway.
Using interrupts would mean when the blitter is already finished when calling WaitBlit() the system has gone through relatively expensive system routines (clear signal, save task pointer somewhere for the interrupt handler, signal task when ready but the signal is maybe never used). There is also chance that task is unloaded from memory before blitting operation is finished what is perfectly legal situation.