Some answers that come to mind:

  - Azul's GC requires cooperation from the kernel; I believe it
    specifically uses the virtual memory mechanism to implement a read
    barrier.  Basically you need a patched Linux kernel.
  - Real-time GC will assuredly lower overall throughput, and increase
    complexity.  At the very least you need either a read barrier or a
    write barrier.  I don't think anyone uses read barriers normally;
    write barriers are often used for generational GC, but I *think*
    the write barriers used for real-time GC involve more work than
    those for generational GC.
  - Adding a read or write barrier to a language implementation that
    doesn't already have them means you need to guard every single
    place where someone reads or writes what might be a pointer.  This
    is easy to screw up.
  - Several real-time GC algorithms punt on moving objects, and are
    thus vulnerable to memory fragmentation.  This obviously reduces
    the robustness of the runtime system.  (Others use stop-the-world
    to do compaction, and thus are not real-time.)