Reasons for going with a property from the start is if you a) ever use reflection (which would need to change depending on whether the storage is a public field vs a property) b) If you need to implement interfaces using the property. Reasons for going with a public field is for special cases where you know a lot about how inlining affects your performance. Typically in structs.
Since there is no more boilerplate used to write "public int Id { get; }" vs "public readonly int Id", in 99% of cases I'd choose the latter.
The only exception here is for public APIs, but that's a minority of projects.
You mean, change it to a property, then fix dozens or hundreds of references, possibly in downstream dependencies some of which aren't under your control and can't be changed. Sounds fun.
fwiw those are both gross but I've run into both in production code (not written by me, naturally)
public readonly int Foo;
readonly fields can only be set in the constructor, great for immutable types and with much better guarantees than protected/private/no setters.