runtime check. Which in turn results in a runtime performance.

If you're calling drop on a mutable string that's been extended repeatedly, you're recursively dropping all kinds of mess all over the heap. Checking for zero beforehand has an insignificant impact. Those cache misses you had because rust pays less attention to "where" than it does to "whether", they cost you a lot more than the reference count check. In the real world, in practice, under profiling of real code, the cache misses and the branch misses are more expensive than the reference counting.

You sound a little bit like a C programmer who claims his code is fast because his arrays don't do bounds checking. That's not why C is fast. Similarly rust isn't fast because it never does runtime reference counting. It does sometimes, but that code isn't pathologically slow.

Also, rust isn't just fast because of the borrow checker, primarily it's memory safe because of the borrow checker.

If it's any consolation, afaik, most of the roc platforms are written in rust. Also afaik only application specific code is written in roc. There are no memory management primitives in roc code unless a platform author exposes them in their api/interface, and I don't think anyone is working on implementing C on top of roc.