It depends at the level at which you're looking. In C# code it absolutely has that hard requirement. But if you swap out a DLL you're calling with one that doesn't actually initialize it, the bytecode verifier is fine with that and will still jit-and-run it.
The other difference is that in C# out is a parameter mode, not actually a type. (See how one cannot make a List<out T>, for example.) Rust could probably implement that without too much trouble, but since &mut is a type, I suspect people would generally expect &lazy to also be a type. And checking that a &lazy T is definitely initialized after it was put into a Vec<&lazy T> becomes exceptionally difficult.
I worry more about things like that because they severely break orthogonality. For the perf-sensitive use cases, &mut, MaybeUninit and unsafe are perfectly fine – there's no need for yet another type of reference.
There are a couple use cases where different reference types would be useful. Not just for performance, but also soundness.
For example, if I've got some *mut Foo, the statement &mut (*some_foo).bar as *mut Bar to get a raw pointer into the bar property may or may not be sound because you create a temporary &mut Bar which isn't guaranteed to respect Rust's rules on references (alignment, dangling pointers, uninitialized memory, borrowing, etc.). The motivation written by RalfJung in RFC 2582 explains it in more detail.