Why ever use fields instead of properties?

Typically, properties need a backing field unless they are simple getter/setter “automatic properties”.

So, if you’re just doing…

public string Name { get; set; } // automatic property

…you don’t need a field, and I agree, no reason to have one.

However, if you’re doing…

public string Name
{
    get { return _name; }
    set 
    {
       if (value = _name) return;
       _name = value;
       OnPropertyChange("Name");
    }
}

…you need that _name backing field.

For private variables that don’t require any special get/set logic, it’s really a judgment call whether to do a private automatic property or just a field. I usually do a field, then, if I need it to be protected or public, I will change it to an automatic property.

Update

As noted by Yassir, if you use automatic properties, there’s still a field lurking behind the scenes, it’s just not something you actually have to type out. So, the bottom line is: properties don’t store data, they provide access to data. Fields are what actually hold the data. So, you need them even if you can’t see them.

Update 2

Regarding your revised question…

is there any time that SomeType someField; is preferable to SomeType SomeProperty { get; set; }?

…one thing that comes to mind: If you have a private field, and (according to convention for private fields) you call it _name, that signals to you and anyone reading your code that you are working directly with private data. If, on the other hand, you make everything a property, and (according to convention for properties) call your private property Name, now you can’t just look at the variable and tell that it is private data. So, using only properties strips away some information. I haven’t tried working with all properties to gauge whether that is crucial information, but something is definitely lost.

Another thing, more minor, is that public string Name { get; set; } requires more typing (and is a little messier) than private string _name.