Because the language doesn’t allow it.
This may seem like a frivolous answer: after all, the language designers could have declared that if you used readonly on an automatic property then it would mean “the property is settable but only in the constructor”.
But features don’t come for free. (Eric Gunnerson expresses it as “Every feature starts with minus 100 points.”) To implement read-only automatic properties would have required additional compiler effort to support the readonly modifier on a property (it currently applies only to fields), to generate the appropriate backing field and to transform sets of the property to assignments to the backing field. That’s quite a bit of work to support something that the user could do reasonably easily by declaring a readonly backing field and writing a one-line property getter, and that work would have a cost in terms of not implementing other features.
So, quite seriously, the answer is that either the language designers and implementers either never thought of the idea, or — more likely — they thought it would be nice to have, but decided there were better places to spend their finite resources. There’s no technical constraint that prevents the language designers and implementers providing the feature you suggest: the reasons are more about the economics of software development.