Extending from the excellent explanation by PhiGuy, my take:
In the programming world, and more specifically in the Object-Oriented world, we have a concept of encapsulation and abstraction.
Encapsulation: I will contain everything you need! Abstraction: I will do whatever you want without telling you how!
Extending the car example, the car itself is an example of an encapsulation; it contains all the components, parts, mechanics and software to help you get from point A to point B. It also employs abstraction whenever you hit the gas pedal, or the breaks, or check the reading on the speedometer; how? You know that when you press the pedal, you will "add speed" to the car; you don't know how it's done, but you know that it is done.
Extrapolating from the aforementioned concepts, we dive into the state of an object; and this is a term which is used very frequently by a developer. Very simple, the state of an object is a collection of the values of its properties at any given point in time. For example, if I ask you what is the state of your car as of now, you'd say - "I have driven it around 4000 miles, the battery is at 11.9 volts, etc." Those properties represent the current state of the car.
With that out of the way, let's focus on the question now. Mutators, as you are aware, change the value of a specific property; accessors get get value of the property. Now, every property is either mutable (changeable); or immutable (permanent).
Now, what good are they?
Continuing the case example, there are things that the service center or the manufacturer want you to see but not change. A simple example would be, say, the "check engine light." The manufacturer wants you to see it but not change it because they want you to go to a service center and get the problem fixed. You get where I am going? This is called data encapsulation and security. You are changing the access modifiers of specific properties on an object (your car). If every one can change a property, it's public; if only the party which "created" it can change it, it's private; if some trusted contacts can change it, it's protected, etc. (You, manufacturer, service center, respectively.)
However, there are some things which should be rather left unchanged. Say, your engine number. This is an example of immutability: stuff you can not change. But there are some things you can change: like the color of your car, or the interiors.
We have a concept of something called a shared-state and most of the times, it's a bad practice. This gives rise to something called a race condition. Imagine, for a second, that you gave the same assignment to a group of five people and told them to work on it; the only condition is that they can not know what the other person is doing. This is a classic race condition; since no one knows what the others are doing, they start making changes to whatever was already given to them. There is a high chance that the others are changing some bits of the same text, too. And this leads to, well, corrupted data.
To prevent this from happening, we use immutability. Very simply, we say: you can do whatever you want with the state (imagine the assignment), but instead of giving you the original document (say a Google Sheet where you can't see where the others are typing), you will all get a copy. This way, they can work on that resource without having to worry about the fact that others might change what they are doing while they are doing it. To implement immutability, we use accessors and mutators (when someone asks for a property, give them a copy; when someone tries to set the value of a property, extend it from the last known - and valid - state.)
Quite interestingly, race conditions often happen in the multi-threading world. When I worked with C#, we used something called delegates (the like of which I won't dive into since that's another article in itself). So, multiple threads were accessing the same resource, and sometimes, because of this asynchrony, tasks gave the wrong output. A property's value was wrong, the key didn't exist, etc. To prevent this from happening, we used to use something called a mutex lock; very simply put, it locks down the resource and gives a specific thread the privilege to change and play with it; once the thread is done doing whatever it has to, the resource is unlocked and given to the next thread in the queue (or a spool).
I hope this made sense. It surely is a lot of text, but I have been as basic as I possibly can! If nothing, I hope you learnt something new! :D