Here are some arguments for properties and my counter-arguments:
Easier to use than writing getter and setter methods
Getter and setter method pairs are a code smell. Making it easier to write these is like making it easier to fail a math test by using a Scantron form and filling in all 'C's. Objects that contain only state, for persistence, shouldn't be using getters/setters and should be creating immutable objects at the time of persistence.
What is important to a consumer of an object is what it does, not how it does it. Its behavior is what it does; its state is how it does it. If you find yourself caring about an object's state (except for persistence, though this also breaks OO), you're simply not doing OOP and losing out on its advantages.
They give a rough indication of performance to consumers
This is something that could change in the future, for any given property. Suppose in release 1.0, accessing PropertyX simply returns a field. In release 1.5, if the field is null, PropertyX uses the Null Object pattern to create a new null object. In release 2.0, the field is getting further validated by the getter method in PropertyX.
As the property gets more and more complex, the performance indication of using a property seems less and less truthful.
They're better than public fields
This is true. But so are methods.
They represent a fundamentally different aspect of an object than a method, and all consumers of the object should care about this
Are you sure that both of the above statements are true?
They're easier to type, man
myObject.Length is easier than typing
myObject.Length(), but couldn't that be fixed with a little syntactic sugar?
Why use methods instead of properties?
No performance guarantees. The API will remain truthful even if the method gets more complex. The consumer will need to profile their code if they are running in to performance issues, and not rely on word-of-API.
Less for the consumer to think about. Does this property have a setter? A method sure doesn't.
The consumer is thinking from a proper OOP mindset. As a consumer of an API, I am interested in interacting with an object's behavior. When I see properties in the API, it looks a lot like state. In fact, if the properties do too much, they shouldn't even be properties, so really, properties in an API ARE state as they appear to consumers.
The programmer of the API will think more deeply about methods with return values, and avoid modifying the object's state in such methods, if possible. Separation of commands from queries should be enforced wherever possible.
So I ask you, why use properties instead of methods? Most of the points on MSDN are code smells in and of themselves, and don't belong in either properties or methods.
(These thoughts came to me after thinking about CQS.)