It seems to me like the endgame of most memory management problems is static buffers and pools for speed/low fragmentation, and GC for everything else; manual allocations are just too fiddly for most coders to favor them for optimization.

Disclaimer: I've mostly worked in GC environments.

You say reference counting is far more expensive, but that's only in CPU cycles. Compare Python (reference-counted) and Java (garbage collected), and Java's memory use is 3x greater for similar programs, at least in my experience (also in the computer language benchmark game). Reference counting is a form of garbage collection, it's just eager rather than lazy, and that eagerness pays off in predictably lower memory usage.

You can save memory by writing a file a byte at a time rather than allocating a buffer. The reason you don't is that it's more efficient to batch that work. Well, the same is true of GC. If you have a million dead objects and a thousand live ones, doing bookkeeping for each dead object is far more expensive (in cycles and bus bandwidth) than just having a copying collector rescue the live objects and then reuse those memory pages en masse.

Once your program's memory footprint is small enough to fit on the machines you're using, making it smaller takes more runtime work but has little benefit.

Also, reference counting can't handle cyclic structures gracefully. Just say no to it.

Reference counting can also become extremely complex (and error prone) in a multi-threaded environment.