Circular imports are not bad.
Dart's circular imports are not related to garbage collection. It's all about making names available to other libraries at compile-time.
Cycles in data structures at run-time may keep objects stay alive (but, unlike some other languages, Dart's garbage collection can collect entire cycles as long as there is no outside reference to any object in the cycle).
Libraries are not data structure at run-time, they only really exist at compile-time.
All the imported libraries exist in the program anyway. If the program uses library A, and library A imports library B, then both libraries will be part of the program (their individual members may or may not be tree-shaken away depending on whether they are actually used or not, but that's independent of the library dependencies.)
If library B then also imports library A, that changes nothing. Both libraries are still part of the program. All it does is to allow members of library B to refer to member declarations of library A.
Cyclic dependencies does affect efficient modular compilation.
In order to compile one library, you need to have compiled all its dependencies too (at least to some extend, which includes type inference), otherwise you can't check whether the library is using its dependencies correctly.
If you have a one-directional dependency, then you can (potentially) compile the dependency completely before you start looking at the library which imports it. Sometimes build systems even allows a library to be compiled once, and then reused in multiple other programs that depend on it.
If you have a cycle in library dependencies, then the modular compiler needs to compile all the libraries of the cycle in the same compilation step, because none of them can be compiled before the others.
So, for a modular Ahead-of-Time compiler, cycles affects the granularity of the modular compilation.
I'd recommend avoiding cycles that go across multiple packages.
Inside a single package, it's perfectly fine.
It still makes no difference at runtime.