Эмм.. ну есть вот такое мнение:
Personally, I don’t like properties and I wish that they were not supported in the Microsoft .NET Framework and its programming languages. The reason is that properties look like fields, but they are methods. This has been known to cause a phenomenal amount of confusion.
When a programmer sees code that appears to be accessing a field, there are many assumptions that the programmer makes that may not be true for a property. For example,
A property may be read-only or write-only; field access is always readable and writable. If you define a property, it is best to offer both get and set accessor methods.

A property method may throw an exception; field access never throws an exception.

A property cannot be passed as an out or ref parameter to a method; a field can.

A property method can take a long time to execute; field access always completes immediately. A common reason to use properties is to perform thread synchronization, which can stop the thread forever, and therefore, a property should not be used if thread synchronization is required. In that situation, a method is preferred. Also, if your class can be accessed remotely (for example, your class is derived from System.MarshalByRefObject), calling the property method will be very slow, and therefore, a method is preferred to a property. In my opinion, classes derived from MarshalByRefObject should never use properties.

If called multiple times in a row, a property method may return a different value each time; a field returns the same value each time. The System.DateTime class has a readonly Now property that returns the current date and time. Each time you query this property, it will return a different value. This is a mistake, and Microsoft wishes that they could fix the class by making Now a method instead of a property. Environment’s TickCount property is another example of this mistake.

A property method may cause observable side effects; field access never does. In other words, a user of a type should be able to set various properties defined by a type in any order he or she chooses without noticing any different behavior in the type.

A property method may require additional memory or return a reference to something that is not actually part of the object’s state, so modifying the returned object has no effect on the original object; querying a field always returns a reference to an object that is guaranteed to be part of the original object’s state. Working with a property that returns a copy can be very confusing to developers, and this characteristic is frequently not documented.

Хотя по моему скромному, это всё как-то высосано из пальца. Со свойствами мне известны на личном опыте только одни грабли - сериализация объектов с AIP.

НемоКэп42Кстати, насчёт медленнее. Если поля это методы доступа, то компилятор их инлайнит, как обычные методы, если они маленькие, или нет?
Сам по себе компилятор C# не инлайнит даже AIP. Инлайн если и происходит, то делает его джиттер, и основанно утверждать, будет он это делать, или нет, невозможно - это механизм неизвестен (но можно уверенно утверждать, что он этого делать не будет - см. про MethodImplOptions.NoInlining ). Ну, и есть мнение , что инлайнинг - не всегда хорошо.

НемоКэп42Насчёт "программист не знает, какое свойство имеет сеттер и открытый ли он, а какое только геттер" - по-моему, это должна решать среда разработки. Жаль, в Студии по-умолчанию не видно, имеет ли свойство публичный сеттер, пока не попытаешься присвоить значение.
Эмм.. у меня видно (см. рис.). Или это я что-то подкрутил в сторону от "по умолчанию"?

НемоКэп42что у вас за стрелочки на картинке какие-то? Какая-то надстройка над Студией?
Это в главном меню Edit->Advanced->View white space, самая что ни на есть родная фича студии для отображения пробельных символов.

НемоКэп42,

решарпер. Проверил сейчас на чистой студии - да, это он рисует разные иконки разных свойств.