Whether reference counting or GC is more efficient depends on your workload. There are common workloads where reference counting is better. And others where GC is better. In general neither can win.

So saying "just don't use GC" as a answer to improving throughput shows ignorance.

So what are the real tradeoffs?

GC is less work. Is easier to get right. And lets you handle complex self-referential data structures more easily.

Reference counting lets you handle real-time constraints more easily. Is simpler to understand. And results in faster freeing of potentially scarce external resources.

Having built reference counted systems, they're anything but easy to understand unless you're greatly restricting the graph of objects and the references they can have to each other. And once you've restricted who can point to what, you've lost a lot of the flexibility that a RC system affords.

The system itself can be hard to understand.

The basis on which the system works is easy to understand.

"So saying "just don't use GC" as a answer to improving throughput shows ignorance."

It could also mean they use Rust, memory pools, some kind of checker that catches those errors, or separation logic. Probably that order due to popularity.

As a counterpoint to "don't use GC," there's also low-latency or real-time implementations of RC/GC to consider as well. A lot of developers using RC/GC languages don't know they exist. Maybe we need a killer app that uses it to spread awareness far and wide. More open implementations of the concept, too.

> there's also low-latency or real-time implementations of RC/GC to consider as well

These exist but tend to have poor throughput, frequently set a maximum amount of memory you're allowed to use, and typically don't perform well when compared to commonly used garbage collectors.