If, like OP, you're writing an operating system (or a language VM) it is absolutely a thing that you will want to have different allocators for different use cases, so being able to set a global allocator is "not quite enough". You will want certain generics (like hashes) to be able to take advantage of different allocators, or even different instances of allocators (say, give each thread it's own arena). This is very not easy in rust, which effectively requires data structures to be associated with specific allocators at the type-level - which makes code sharing between the "same" data structure tied to different allocators quite difficult.
For reference, the Erlang VM, which is often joked as being "an operating system unto itself" has 11? IIRC allocators.
The rust compiler makes use of custom arenas for allocation, quite heavily in fact. And does it without using the nightly-only custom allocator alloc types. Instead, there are functions that let you build structures inside the arena, plus a bunch of macro logic that builds on it. And while rustc generally uses a lot of nightly features, there is nothing fundamental about it that requires nightly.
Also, again, it's a fair concern that you want to be doing custom allocators, but this is not the same as claiming that no-std applications can't use the heap at all, which is what the blog post did. For simple heap usage, a global allocator is enough.
For reference, the Erlang VM, which is often joked as being "an operating system unto itself" has 11? IIRC allocators.