There's a couple big reasons, sometimes you only have to deal with one or two, other times you're hit with all of them.

The data source for the algorithms often comes from arbitrary memory addresses that live outside the context of the C, C++, or Rust runtime. If I want to read CPU core temp I send magic numbers to one address to configure ADC channel conversion, another magic number somewhere else to do the conversion, wait a few dozen microseconds, then read a third new address that I squint one eye, spin around 10 times, and do a handstand and I'll get a number that looks like temperature.

If I'm running on the microcontroller, I'm essentially in production environment and I can't control what the data is. If I recompile for a different system (say x86 Linux) then I'm almost certainly going to segfault. I could abstract out the reading of the data, but then on my tiny 8MHz microcontroller that has to run it's main loop at 1000Hz, I only have a few thousand clock cycles to get everything done, calling functions, pushing/popping the stack takes a lot of time.

Adding to the pile-on most microcontrollers have <1MB of RAM, many in the tens of kilobytes range so I don't have much of a stack to work with and I need to keep even the number of instructions down.

Even if you do all the abstractions, you then have extra logic you have to write to simulate what is happening and subtle behaviors that are timing dependant. It frequently is extremely difficult to do that as the documentation rarely fully describes everything, so you can lull yourself into a false sense of security that you've tested the code and it's correct, but then you get stuck on a register value that never changes and a watchdog timer comes along and resets the hardware on you.

And that's not the getting into the runtime or build environments, flashing procedures, limited flash cycles, and a million other business constraints that technically you can do it, but at that point your dev team has all taken the month off to go play Half Life 3