|Problems? Is your data what you think it is?|
Timely destruction is lost by dragooning mark-and-sweep gc into the quest for correct destruction of circular chains of reference.
While I think that correct destruction of circular references is more than enough reason to move to a decent GC system it's not the only reason.
A sane GC is also faster than reference counting for all but the most pathological of cases (you don't have to keep track of references and you get better use of your cache).
It's also much more robust. Once you have it up and running it "just works". With reference counting add one feature that forgets to bump/decrement the reference count and you're in trouble.
Personally, I think that the worries about timely release of resources and GC are overstated. I've spent a lot of time before Perl in languages with a decent GC. I can't recall a single instance of timely destruction being a problem. Arguing from personal experience is dodgy I know - but I really don't think you'll have problems. You might have to add a couple of extra techniques to handle things (e.g. block-exit handlers) - but it won't be hard or onerous..
It will be a problem for some Perl5 code running in Perl6 - not a huge amount if my code base is anything to go by. I've got much more code that has to jump though hoops to deal with circular references. The thought of throwing all of that in the bin gives me the warm fuzzies :-)
For new code there are several ways of manging timely release of resources in other ways. Perl6 has block-exit handlers, and probably other timely finalisation methods that we've not heard about yet.
For me the advantage of a decent GC more than make up for the lost of calling DESTROY when something drops out of scope.