Incremental garbage collectors don't remove jitter, they just help to mitigate it. Like generational collecting, it's an optimization. But there will always be jitter associated with GC. Whether you can perceive it or not is another matter.
What sells me on GC is the ability to handle things like lexical closures without trouble. Closures really cry out for GC, otherwise it's much too easy create cycles (as happens in Perl 5, often).
And the ability to manage external resources is largely a red-herring. A properly implemented C or C++ class will use reference counting internally, so that script references merely holds a lease, and don't control the lifetime, per se.
"Improperly" implemented classes however... well, if you're just tossing garbage C code into your application, then I have no sympathy for you. And adding a simple ref count should be easy enough.
As for GC memory leaks, AFAIU these are usually associated with caches, where you can create undetectable cycles between the key and the value in the cache. These can be solved by "ephemeron tables", although they're not computationally cheap. But then again, nothing is preventing you from manually breaking the cycle.