This allows you to override the logic later. Public fields in a language where "x.y" means "directly access field y on value x" don't allow that; x.y forever means "directly access field x" and you can't later interpose code between attributes and the code accessing it.

This isn't the only way of doing it, depending on your language. Python has a completely different mechanism where a class can start with a directly-accessed "y", but in a later version make it a property. (More than one, actually.) Some languages route all property accesses through something you can hook. Some languages simply automatically do what C# is doing here.

Semantically and abstractly, there's no reason to every not be able to override a property access in later versions like that, because it is so darned useful. Unfortunately, performance wise, it's hard to beat a language that guarantees structure layout and guarantees that x.y can be compiled into a single constant memory load instruction, and unfortunately, you can't just wave "compiler optimization" at the problem and make it go away (considered in isolation this seems like an obvious solution but as usual as it starts interacting with all the other features it gets much harder than the simple cases). The higher performance languages have a strong reason to give people ways to get guaranteed direct struct member accesses.

Though please note that if you "upgrade" anything from a field to a property, you need to recompile any dependencies. Otherwise they will obviously try to invoke the field that no longer exists, instead of calling the property methods.

Not if you need to implement some setter logic though, or want to reserve the option to do so in the future. And not if you want those instance variables to be available as JavaBean properties.

I haven't developed in Java in a long time, but public instance variables were a no-no when I did for these reasons.