Protection. Some properties/methods shouldn't be called from without the class...ever. I'm sure you maintain the sole authority to tell anybody your social security number, right? They have to ask you (getter)? Certainly you wouldn't advise we allow people direct access to private data/methods in our own lifes...why treat your applications any different? :)
One way that I've found it to be helpful is to be able to set a breakpoint on the set (more so than the get). That probably means "I'm coding it wrong," but at least I can find out exactly when it changes.
Here is Allen Holub (who is brilliant) on the matter. He goes into much more detail on this subject in Holub on Patterns. Some things require public getters and setters like serialization and patterns like the Data Transfer Object pattern. In general, I think necessary evil since your application becomes convoluted when you don't use them.
Getters and Setters hide your classes data specifics from the users of your classes.
In many cases they are not fully utilized, but it is always a good idea to use them. Direct access to your objects data reduces encapsulation.
If you don't use getters and setters, when you change your mind about a data member, you break your classes interface, and must alter the rest of your codebase to conform to the change. In some cases where your class represents part of a public API this isn't even possible. If you wrap your properties in getters and setters you can make those changes, and hide them from consuming code by modifying the getter and setter methods.
Getters and Setters are one aspect of implementing the Open/Close principle. If you encapsulate all of your functionality behind proper properties then code that uses your properties won't break. It also makes it possible to completely replace that object with something else in the future -- espcially if you code to an interface instead of a class.
They are so important that C# went through the trouble to make basic getters and setters easy to write.
To further understand why some aspects of OOD is important, read the book Emergent Design by Scott Bain.