This is very closely related to the recent discussion about weak let.
Swift has evolved such that let and var really refer to ownership, not mutability. A let variable/property only exposes operations that can be done with shared ownership. A var variable/property can also expose operations which require exclusive ownership. Since a lazy variable mutates its storage on first access, it must be a var.
Atomics are the exception that proves this rule: they must be declared let, but they support mutating operations. This is because a mutating atomic operation is defined to not require exclusive ownership. Shared mutability is the whole point of atomics, after all. But it does mean if your type contains a public atomic property, you can no longer rely on the law of exclusivity to protect that value’s in-memory representation.
lazy is not currently thread-safe, but a hypothetical thread-safe version of lazy could theoretically be declared let. But that would significantly expand the aforementioned hole in the law of exclusivity. The Language Workgroup argued that anyone writing an atomic variable is opting into the paradox of mutability under non-exclusive ownership. I doubt this would be considered true of lazy let.