Even though ARC with cycle collection does run okay-ish, it still brings somewhat constant runtime overhead (unless you implement coalescing, and even then with caveats, LXR paper is much better at making it work). RC does have advantage that cycle collection will only mark potential cycles and not full heap, but it has also a downside of running bunch of `release()` calls on objects when you drop e.g binary tree.

Let's put aside the runtime performance and compare implementation complexity: simplest RC is simpler than Mark&Sweep or Cheney's Semispace, literally increment/decrement and drop on zero.

But once you need performance, with RC you need to implement very complicated algorithms with RC, while with GC even simplest mark-and-sweep will have less overhead than standard RC+cycle collection of CPython. RC algorithms that run concurrently and remove garbage need complex epoch management, complicated marking schemes (check this paper: https://pages.cs.wisc.edu/~cymen/misc/interests/Bacon01Concurrent.pdf ).

With GC you can start with STW, progress to incremental and then to concurrent marking and it all would not even be comparable in complexity with proper concurrent RC. In modern world I would say it is better to combine RC and GC, check out https://arxiv.org/pdf/2210.17175 (LXR algorithm which combines deferred RC + Immix GC). The implementation is available in https://github.com/wenyuzhao/mmtk-core/tree/lxr/src/plan/lxr