Often you don't allocate because it's not a necessity and a PITA due to C, but with rust I see no point in not using a tiny allocator if one has a few 100 KiB of RAM - totally depends on the project and target platform.

> No multi core = no atomics or concurrency to worry about.

There are interrupts though and those just need the same mechanisms than multicore and can be a PITA to manage in C. Besides that, there are quite a few cheap multicore embedded CPUs available now.

You can encode safety checks like pull-down/up clashes and the like nicely via the rust type system, that alone makes it a major benefit over C.

For example, from the rust embedded book:

    One can also statically check that operations, like setting a pin low,
    can only be performed on correctly configured peripherals.
    For example, trying to change the output state of a pin configured in
    floating input mode would raise a compile error.

- The package management is a nice. Install a generic ring buffer or a board support package for the hardware you are using.

- Async-await can be really nice for dealing with hardware peripherals.

- Don't interrupts constitute concurrency?

- Reduced UB and footguns compared to C

For example, your i2c controller only supports two specific pins and they have to be in a specific mode? That can be a compile error if you make a mistake.