You should not think of it as malloc replacement but as an GC that can work with native code that does not use fixed stack and register layout. That you can use such a thing for code generated by C compiler is side effect of that. In fact, there are various garbage collected runtimes with bespoke GC's that use similar implementation strategies.
Edit: and one notable thing on BDW GC is its non-oddballness when it comes to building and/or packaging it. Also it is almost completely written in portable-ish C (it expects sane memory layout and relies on bunch of technically unspecified, but expected behaviors).
The point is that it's designed to work with native code in a language that wasn't designed to use garbage collection. That's going to result in a semantic gap no matter what, and it invariably does.
Every system I've ever seen using Boehm GC has issues as a result, except in certain special circumstances where the limitations are mitigated by the nature of the system. That's not an indictment of the GC itself, it's simply a consequence of trying to shoehorn automatic GC into a language that doesn't support it.
Edit: and one notable thing on BDW GC is its non-oddballness when it comes to building and/or packaging it. Also it is almost completely written in portable-ish C (it expects sane memory layout and relies on bunch of technically unspecified, but expected behaviors).