Edit - Looking over this, my bias is (even to me) painfully obvious.
Coming from OS' that always give ultimate priority to the kernel (and thus will never allow a single process to assume complete control of a system), Amiga OS has been (somewhat) disappointing.
So...by common definition, using the term preemptive is acceptable (even if this can be defeated) AND prioritization has previously been documented.
So... I'll cede this one to you guys.
With the qualifier that it is a piss poor implementation of preemptive multi-tasking.
The AmigaOS requires cooperation between good behaving preemptively multitasking tasks. Again, this was a tradeoff of security (and to a lesser extent stability) for speed and ease of use. It was a better trade-off back in the day when CPU power was more limited but I would argue that the advantages are under-appreciated today. Would there be Amiga users today if the Amiga ran at the speed modern secure operating systems would run on a <100MHz 68k CPU? Would the Amiga be as fun and easy to use?
Which leads me to a question: Why is there Forbid() and Permit() in the first place? Apart from shutting the OS down I see no reason for those functions to be there at all.
Resources need to be shared with a multitasking AmigaOS and the 68k and locking CPU instructions (CAS, CAS2, TAS) didn't work correctly because of the way the memory bus was accessed with the custom chips (cache coherency issues between the CPU and custom chips). C= could have solved the problem if they made (or licensed) their own customized CPU to go with the custom chips but that was exceedingly expensive back then. This is no longer a problem today in FPGA (SMP should be possible too).
Forbid()/Permit() are not as big of worry as exec/Supervisor() and dos/Format(). The Amiga will never be as secure as BSD but there are a few things we could do to improve security (or at least improve stability and make it quick and easy to recover and restore from problems).