There are 3 ways to get a memory leak in a perl program: construct a circular reference (as described by other comments above); find and tickle a bug in perl's reference counting; or find and tickle a bug in some other external non-perl code (such as an XS library).

And those potential bugs in the perl interpreter and XS libraries are IMO the biggest drawback of a reference counting scheme. Circular references in perl are usually easily avoided (you can now even use weakrefs with the standard distribution if you need to) - but when you're writing extensions or modifying the interpreter you need to get the reference count correct in all C/C++ code using perl's data types. This is extremely brittle, when you consider passing subroutine arguments, changes in scope, stuffing data in lexicals, mortal SV*s etc etc. At least, I usually mess it up hard :-)

As far as I understand it, a "real" garbage collector can replace most of this mess with a centralized (but complicated) garbage collection algorithm. at the cost of (usually) not guaranteeing a specific destroy time for objects (perl objects are at the moment guaranteed to be DESTROYED at the exact moment they go out of scope). AFAIK perl 6 is going to implement a scheme like this - which means you won't be able to count on "timely destruction" in perl 6 (at least, last time I looked).