GP's solutions to problems 1 and 2 are the same as Rust's; the difference is problem 3 ("temporal memory safety"). Rust solves this problem with statically analyzed lifetimes, which, in addition to the safety and correctness advantages of compile-time checking, also permit RAII (which answers your "natural question" with "no, it's not necessary to do that"), which makes programming more pleasant. The disadvantage is, as you said, language-level complexity, since it's not enough for the programmer to be personally satisfied that the lifetimes are correct; they have to be represented in the code in a way that satisfies the borrow checker.
GP's proposal is to drop lifetimes and RAII (thereby simplifying the language semantics), make the programmer responsible for allocations and frees (as in C), and solve the temporal memory safety problem by doing additional work at runtime to ensure that use-after-frees reliably crash the process instead of overwriting return addresses or doing other arbitrarily bad things. Whether this is more fun to program in than RAII depends on whether you think it's better to suffer from too much abstraction or too little; people have sharply diverging intuitions on this and it's been a holy war since forever and it probably always will be.
The clearer-cut problem is that such a language would be slower than C or Rust, both because freeing memory involves extra work that C and Rust programs don't have to do, and because the requirement that use-after-frees must reliably behave a specific way inhibits optimization, since the compiler can't assume that use-after-frees don't occur. Also, using memory from a small allocation that's been zeroed out doesn't reliably crash the process unless a pointer in that allocation is dereferenced, and even then, this (contra point 1) would require the compiler to assume that null pointer dereferences can happen and must segfault, which, again, inhibits optimization.