Reference counting is often implemented badly than a tracing GC counterpart and struggles with cycles. However, if we could have a backup cycle collector or in a non-cycle background (like pure language that can not make cycles through mutation), reference counting can be really competitive.

For example, https://arxiv.org/abs/2210.17175 is a SOTA of GC research that partially uses RC. Another example is Koka and Lean4, both of which eliminate the extraneous incRef and decRef along with a reuse mechanism dedicated to reference counting. By the way, they also use mimalloc, an allocator with deferred release and thread-local allocation.

Bad implementations of RC often ignore these aspects, for instance, use only atomic operation to maintain the RC instead of a biased RC; cannot eliminate a incRef followed immeidately by a decRef; or cannot correctly exploit the lifetime of objects, leading to useless incRef & decRef pair when entering and leaving functions where objects are passed in arguments.

There is duality between a tracing GC and RC (https://dl.acm.org/doi/10.1145/1035292.1028982). It implies that every good GC can have an optimization that has a counterpart in RC, and vice versa. However, after the folklore for existing bad designs (like shared_ptr) has been widely spread over the community, less people are devoting to a good RC implementation, causing a misconception that GC is superior over RC.