ES6 getters and setters have a substantially different motivation than similar concepts in Java.
In Java, getters and setters allow a class to define a JavaBean. The point of getters and setters is that it allows the bean to have a completely orthogonal "interface" from that implied by public fields. So I can have a field "name" that is is NOT a JavaBean property, and I can have a JavaBean property "address" that is NOT a field.
JavaBean properties are also "discoverable" by thousands of frameworks (Hibernate for example) via Java reflection. Thus, getters and setters are part of a standard method for "exposing" bean properties.
Getters and setters, being functions, also have the value that they "abstract" the implementation. It can be EITHER a field or a computed ("synthetic") value. So if I have a bean property called "zipcode", that starts out as stored string. Now suppose I want to change it to be a value computed from address/city/state?
If I use a field, this code breaks:
String zipcode = address.zipcode();
But if I use a getter, this does not break:
String zipcode = address.getZipcode();
JavaScript doesn't have anything like JavaBeans. So far as I've read, the intended value of GET and SET is limited to the aforementions "synthetic" (computed) properties.
But it's somewhat better than java in that while Java doesn't allow you to compatibly convert a "field" to a method, ES6 GET and SET allows that.
That is, if I have:
var zipcode = address.zipcode;
If I change zipcode from being a standard object property to a getter, the above code now calls the GET function.
Note that if I didn't include GET in the definition, this would NOT invoke the zipcode GET method. Instead, it would merely assign the function zipcode to the var.
So I think these are some important distinctions to understand betweeen Java and JavaScript ES6 getters and setters.