> You can very much translate C to Rust on a function-by-function basis, the only issue is at the boundary
Absolutely not. There are many restrictions of Rust that will prevent that. Lifetimes, global state come to mind first. Think about returning pointer to some owned by the caller - this can require massive cascading changes all over the codebase to be fixed.
> You can use either unsafe Rust or, in many cases, less idiomatic but still Safe Rust to sidestep them. (For instance, "aliasable mutable" but otherwise valid references which can often be expressed as &Cell<T>, etc.)
There's no doubt that one can convert C into unsafe Rust - C2Rust can automatically convert an entire C codebase into unsafe Rust
The problem is that after such step (which is certainly valuable), converting the code to safe Rust is typically a lot of work, which is the point of the academic research in question. Half baked code, using safety workarounds, doesn't provide any value to a project.
unsafe rust still has to follow invariants, you're just promising the compiler that it does
These are restrictions of idiomatic Safe Rust. You can use either unsafe Rust or, in many cases, less idiomatic but still Safe Rust to sidestep them. (For instance, "aliasable mutable" but otherwise valid references which can often be expressed as &Cell<T>, etc.)
You might still need a "massive cascading change" later on to make the code properly idiomatic once you have Rust on both sides of the boundary, but that's just a one-time thing and quite manageable.