Encapsulation of a domain concept. An Address is not just any string , a Price is not any number/decimal . VO represents a valid value of a Domain concept expressed as an object. Note that 'a' value doesn't really mean encapsulation of 1 primitive. You can see here an example of how I've modeled some value objects.
No.
It's not a rule. A property of an entity should be of type that makes more sense. Some represent domain concepts, other represent more general concepts (like Email) and other are just primitives.
Not really DDD, that's proper OOP. The point is you want to encapsulate behaviour. Setting a property is just a simple assignment. DebitToAccount is a semantic behaviour of the object that may be implemented only as a property assignment. Things can easily change and you want only that object to know about those implementation details. The behaviour itself stays, implementation can change anytime (ex: a new business rule is required).
At least in C# you don't really need ChangeName(), you can put the implementation in a setter. There aren't rules, not even principles in this scenario, it depends on developer style.