Edit: Rewritten to convey my point better.
1: Entity Relationships
I have run into this problem with entities. Suppose that have two classes, Author and Article. Furthermore I have a render(Author) and render(Article) which return html documents describing either item. The author will have a list of articles and the article will have information about the author.
Author and Article will have a reference cycle. We can attempt to solve this cycle by introducing a weak reference. What if the reference is from Author to Article? Then render(Article) will not keep references to Author alive and thus will the object will be deallocated before it is used to get the Author's name. But, if the reference is from Article to Author that works fine, but render(Author) will not register any references against Article and they will be deallocated before their titles can be fetched.
Introducing weak references solves the problem so long as all of the relationships have a definite direction where the opposite direction is clearly secondary. But some relations do not work that way.
On the other hand: This precise problem only derives in cases where we have associations between objects. That is each object needs to hold a mutual reference to the other. Perhaps the language could support such associations naturally and thus give them special treatment with reference counting. That could be made to work.
2: Data Structures
Data structures very often have reference cycles. The most common example is a doubly-linked list. It is also not uncommon for tree structure to have next/prev pointers in the leaves for quick iteration.
On the other hand: I suspect most such cycles are actually broken by the operation of the data structure. For example, when an object is removed from a linked list, the two references to the node will be reset thus clearing the references.
3: Deterministic Deletes
One reason to use reference counting is that you get deterministic deletes. Objects will be deleted at predictable times. This means you can do things like close files, release locks, etc. because you know the objects will get deleted in a timely manner.
The problem is that this tends to breaks. If I accidentally create a cycle my files do not get closed and my locks do not get released. Furthermore, I receive no errors as a result of doing this.
This isn't really a problem with reference counting. It is a case where the advantage (deterministic deletes) does not really work out leaving me with less reason to want reference counting.
On the other hand: The real issue might be argued to be that we did not have any automated testing to ensure the objects were destroyed. If had such a thing we would be informed when this didn't work.
Another reason to want reference counting is because it is faster. However, it seems this is not actually true. All the increments and decrements are actually pretty expensive. (It gets really bad when you start considering threading.) So its not clear that any speed advantage is gained here. In fact, it may be faster to use another GC technique.
If working in a reference counting language, I have to worry about not creating reference cycles. I found myself creating cycles on a regular basis. In most circumstances I could fix this by introducing a weak reference. But why bother? There did seem to be some advantages to reference counting but they didn't seem to pan out (See 3&4) As a result, it just didn't seem worth it to fight the cycles.
Reference Counting simply doesn't seem to deliver enough benefits over typical GC implementations to make up for the extra headache it gives the coders.