Our current (preview) bits only provide a LazyInit type, and as you observed (and JaredPar correctly diagnosed) we restrict T to reference types so that we can: (i) make LazyInit a struct, and (ii) provide reasonable default behavior via CMPXCHG (i.e., we can check for 'null' to mean the absence of a value). We could have made T unrestricted, but decided to optimize for the common case -- doing otherwise would have meant a few extra bytes; believe it or not, this might've made the type prohibitively expensive for some folks.
We've recently changed course slightly. We currently plan to offer a LazyInit type where T is unrestricted in addition to a LazyInitField type where T is restricted to reference types. The former is what most people will use, but the latter can be used for those who are perf-conscious and can live with the restriction on T.
Hope this clears things up. Cheers,
---joe duffy, pfx dev lead