The main problem is that it isn't a very good knob for this use case, as "ratio of freshly allocated data to live data remaining" is only incidental to the goal of the person writing the program. Therefore you'd expect to have to retune it due to unrelated changes, like if you allocated a big chunk of static memory to hold results.

I expect Go's current behaviour is right for memory-intensive programs, where "limit the wasted memory as a ratio of the actual working set" is a reasonable high-level goal. For a CPU intensive program you might have preferred a "max x% CPU overhead" knob, but just a minimum memory size would work, as this is mostly an artifact of the very small memory usage of benchmark program.

Java's G1 has "max pause delay" as their preferred knob, but Go has stuck that knob on low since around version 1.6, which is a good choice for what is essentially a language for network services.

The problem of software knobs is that the one that helps you is almost never there, and you usually can't get similar functionality from mixing the ones that are there.

That said, there are exceptions. I don't think GC is something simple enough to be an exception, but those exist.