C syntactically is straight forward, but conceptually may be harder than Rust. You’re exposed to the bare computer (memory management, etc) far more than with a GC language or even Rust arguably, at least for simple programs.
Towards deployment is even harder. You can very easily end up writing exploitable, unsafe code in C.
If I were a Python programmer with little knowledge about how a computer works, I’d much prefer Go or Rust (in that order) to C.
This is true, but when you get something wrong related to the memory model in C, it just says "segfault". Whereas in Rust it will give you a whole explanation for what went wrong and helpful suggestions on how to fix it. Or at the very least it will tell you where the problem is. This is the difference between "simple" and "easy".
That applies only if you take "memory model" to mean modeling the effects of concurrent accesses in multithreaded programs.
But the term could also be used more generally to include stuff like pointer provenance, Rust's "stacked borrows" etc.
In that case, Rust is more complicated than C-as-specified. But C-in-reality is much more complicated, e.g. see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm
The model you're referring to, a Memory Ordering Model, is literally the same model as Rust's. The "exception" is an ordering nobody knows how to implement which Rust just doesn't pretend to offer - a distinction which makes no difference.
Towards deployment is even harder. You can very easily end up writing exploitable, unsafe code in C.
If I were a Python programmer with little knowledge about how a computer works, I’d much prefer Go or Rust (in that order) to C.