The explanations you quoted make sense from a semantical English point of view, but they are horribly ambiguous because it uses words that have very specific meaning in software development terms, but he's relying on the common English definition of these words.
This book was released 31 years ago and I suspect that it was ahead of what is now considered common OOP jargon, so the correctness of its words has changed because the world changed, not the book itself.
This book was revised 13 years later, and I suspect they may have modernized parts of the semantics (e.g. your third quote), but inconsistently so (e.g. not the first and second quote).
The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties
I believe he's talking about strong typing here, i.e. the fact that an object has a given type, which has a predetermined structure (i.e. an explicit class definition with methods, properties, ...) and that this structure is defined during design time (i.e. pre-compilation) but that the values stored inside are usually not known at design time, only during runtime.
What I suspect he is not talking about, but totally seems like he is at first sight, is static vs non-static properties.
If my interpretation is correct, then "state" here is not intended to mean "stored information" (as in: state vs behavior), but rather "structure of the class" (as in e.g.: the state of the union).
Another property of a vending machine is that it can accept money. This is a static (i.e., fixed) property, meaning that it is an essential characteristic of a vending machine.
The same trend of using semantical English continues here.
By "static", just like before, he seems to mean "part of the class definition", not
By "property", it seems he means the common English word for "trait" or "characteristic", e.g. in the sentence "Each of these states of matter is characterized by different physical properties".
In more modern language, we would now say that accepting money is part of the contract of a vending machine.
This quote is not trying to distinguish properties from methods. It's saying that the ability to accept money needs to be part of a vending machine's public interface. The quote leaves it unspecified as to how this should be added to the class, but I do agree with you that this is obviously a method, not a class property.
All properties have some value. This value might be a simple quantity, or it might denote another object.
And then here, it seems like we've suddenly switched to using specific developer jargon. If you forget the earlier quotes, this statement makes perfect sense, essentially explaining that state is stored in class properties (whether static or not).