Maybe in the non-atomic case. Atomic refcounts force synchronization between CPUs when different threads access the same data, even if they only read it; that can have a quite significant cost.
They also tend to prohibit some smart gc optimisations like moving your shit while you're not looking, and the cache behaviour can be bad because either,
- the data isn't stored next to the count so you get two pointer indirection per access, or
- the data is stored next to the count, and the object gets cached-in when it gets collected.
Piggybacking on the thread because I haven't had much concrete experience with smart pointers: how does the "circular chain" problem seem to manifest? Is it
- "goes wrong quickly," usually picked up and fixed without too much trouble,
- "like any old memory leak" -- maybe a problem if processes run a long time, hard to track down, or
- devs are usually smart enough to see them coming, knowing to keep the "has a pointer to" relation a partial order (either by type or some other natural hierarchy.)