It's always been the case, as far as I know. You may be thinking of the fact that you can't ptrace a process that's already being ptraced, which includes processes that are ptracing themselves.
Any program that interacts with the OS - interacting with files, allocating memory, etc - will have to make system calls. Whether it's in C, Rust, Zig, Haskell, APL or Prolog.
I want to note that this is also true for “managed” languages like Java and Python.
However, because these languages have a far heavier runtime than the “systems” languages, it is usually possible to trace them at the runtime level rather than the syscall level, and doing that will typically give a better experience.
You troll, but I'll feed you. There is no universally better language for portable high-performance system programming for resource constrained platforms. Every single alternative have unacceptable trade-offs.
Not easily portable to most microcontroller targets: No SDK for our target SoCs and official SoC/µC support. Increased code size (which is also a performance issue in many SoCs). High cost of retraining engineers. High cost of reenginering existing code base and tooling. Lack of commercial support.
I'm optimistic about Rust, and it taken great strides to replace C, but there are still many hurdles that prevent it replacing C in microcontrollers and SoCs. Even if it wasn't for the lack of a platform SDK and porting existing code, the risk is too great with lack of official support for many commercial SoCs.
ARM cortex, riscv and espresif all seem like they have first class support. Unless you are talking about peripherals in which case, why would you expect the language to write/maintain low level drivers?
The hurdles to replace it in micros might be worth it depending on the team size and requirements. Personally, I wouldn't expect it to ever replace existing code bases, but could be a reasonable choice for greenfield designs.
In my case, wireless SoC chips (BT, BLE, DECT). Current generation are ARM M0 cores, but 16-bit RISC/CR16 architectures are widespread still. Not expecting language to provide platform support, but SoC providers don't either. They provide C frameworks only, if anything.
Enough with this constant insecurity that forces people to derail every damn unrelated thread with drive-by comments about how C programs should be rewritten in a different language.