Paula's audio buffer size is limited by the custom chips (easily fixed with enhanced custom chips). The Amiga serial ports were limited to low speeds because of limited buffer size support. Amiga IDE was limited by small buffer sizes (and old PIO modes) until the 4000T. Without proper buffer sizes, the CPU has to do more work and the Amiga with 68k CPU has a limited pool of CPU cycles to start with. Buffer sizes were probably adequate when the Amiga was created but were barely or in most cases not upgraded with ECS and AGA. The Amiga did receive expansion boards and accelerators which fixed many of these bottlenecks.
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?
Try to run simple non-IO real time task at priority 0 and GCC below 0.
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.
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.
Try installing Windows XP on an old 386, 486 or Pentium CPU to see how responsive it is in comparison to a 68k Amiga.
But Windows XP has lot more features than Amiga, like memory protection, built-in TCP/IP and USB stacks, and bunch of services (like you mention below).
I had the fan die in an old laptop with Pentium M (roughly the performance of a Pentium III at the same clock speed but more efficient on power) which caused the clock speed to run at 800MHz. Responsiveness was worse than most 68k Amigas even though it had some processing power in slow motion. These modern OSs with their security, features and bloat have a lot of overhead. MOS PPC Macs also are more responsive and performance efficient than with their previous Mac OS X. Any surprise?
Sure. No surprise there. But on the other hand raw performance is still same. Heavy computational tasks run roughly at same speed and it is not possible to have significant gain in the RC5-72 contest for example.