It's not really disputed since musl without mimalloc has a 144% overhead, so most of the performance issues do indeed come from the allocator, by a pretty large margin (~85% of it). Not only that, but some of the "other code" performance hit might still come from the allocator: when you set a global allocator on the Rust side, musl still uses its own allocator internally (as demonstrated by https://github.com/BurntSushi/ripgrep/issues/3494).

And the compounding issue is that the allocator issues get significantly worse as parallelism increases, as the allocator is serial, so as concurrency increases so does the impact of the allocator, which is not the case for most of the "regular slow" code (of musl), those have a relatively constant overhead per thread.