OCaml is already a good language for systems development - people are far too scared of garbage collectors. And if you make the changes in the article then I think you give up most of the concrete benefits of non-GC - you won't have easy C interop without control of stack/heap/allocation, and since trait objects could end up nested arbitrarily far, I think you might still get GC-like pauses where a simple-looking code line ended up doing an arbitrary amount of unwrapping and freeing work.
I guess it depends on your definition of systems development. If you mean "writing systemsy applications" like IoT things or whatever, sure, fine, a GC isn't going to be an issue and probably will help.
If you're talking about a language to write drivers or an operating system, etc in then a GC is just a big No. In that domain we don't even have Malloc/Free, let alone GC services. Having the overhead and normative lifestyle assumptions of _any_ kind of runtime is a big Nope.
OCaml has for and while loops. Its for loop is even more imperative than Rust's (which simply drives an iterator, whereas OCaml's has "for a to b" and "for b downto a").
