Unfortunately, this can lead to wired-in assumptions, such as reference counting which can lead to extension libraries relying on header files to do reference counting logic. The better option, imho would be to instead require extension libraries to 'pin' objects because they've been passed though an FFI.
If a language implementation were to provide an opaque interface of "I am holding onto this object", "I want to allocate an object", "I want to read/write this object's element fields", a far better GC can be provided at a later date while retaining backwards compatibility.
Why go through all this hassle for extension libraries? Because then your GC implementation is completely decoupled from libraries. And most language implementors sufficiently well read to know how to apply GC, but a little ignorant of providing space for a complete decoupling of GC.
Turn GC into an interface and you can provide very advanced GCs if you can find someone to write them. E.g. Java's G1GC for ruby.