Technisch gesehen (auf MSIL-Ebene) ist ein Feldzugriff etwas anderes als ein Property-Zugriff. D.h. wenn Du erst mal mit dem Feld arbeitest und später merkst, daß Du doch eine Property brauchst, dann mußt Du jeglichen Code neu übersetzen, der auf das Feld Name zugreift - auch wenn die Syntax für den Zugriff beim Verwender exakt die gleiche ist(*).

Und warum könnte es passieren, dass Du eine Property brauchst?

• Name soll in ein Interface ausgelagert werden. In Interfaces gibt es keine Felder.
  
• Du mußt INotifyPropertyChanged implementieren, so daß für jeden Schreibzugriff auf Name das PropertyChanged-Event ausgelöst wird
  
• Du mußt irgendwelche anderen Dinge tun, wann immer auf Name zugegriffen wird
  
• Der Wert wird nicht mehr direkt gespeichert, sondern aus anderen Feldern berechnet. Z.B. könnte Name aufgesplittet werden in Vorname und Nachname
  
• Es soll nicht mehr jeder in das Feld schreiben können.
  
• Du willst Name für Datenbindung verwenden.
  
• ...
  

Weil es also normalerweise nicht abzusehen ist, ob es nicht doch mal eine Property werden soll, und weil das dann eine Änderung mit potentiell größeren Auswirkungen wäre, lohnt es sich, von Anfang an auf Propertys zu setzen.

Außerdem gibt es meist ja auch noch Felder, die privat bleiben sollen, und mit Propertys erreicht man eine bessere Abgrenzung zwischen dem internen Zustand und dem öffentlichen Zugriff auf das Objekt.

Übrigens: mit automatisch implementierten Propertys (für die es obendrein das Code-Snippet "prop" gibt), ist sogar der Schreibaufwand kaum größer:

class Klasse3
{
   public string Name { get; set; }
}

(*)Update:
Einen Fall gibt es, in dem der Code des Verwenders nicht nur neu übersetzt, sondern sogar umgeschrieben werden muss, wenn ein Feld durch eine gleichnamige Property ersetzt wird: Felder lassen sich als ref-Parameter an Methoden übergeben, Propertys hingegen nicht.
Und auch der Zugriff per Reflexion gestaltet sich unterschiedlich, aber wer so tief einsteigt, sollte wohl sowieso genau wissen, was er tut.