https://news.ycombinator.com/item?id=15607812
There simply isn't a better domain method term for moving data from one place to another than get/set. You could invent alternatives but they're just more confusing.
And even that linked comment addresses modification not retrieval. Sometimes you just want a value out of an object -- a getter.
I think understand the point that you're trying to make; the idea that an object just accepts messages that alter it's internal state but otherwise keep it completely hidden is a pervasive one. Exposing internal state can lead to coupling or violate the single responsibility principle. But that model is too simple, plenty of objects are just containers. And not dumb containers that are just bundles of simple fields but smart containers with data that isn't entirely internal.
The getter or setter is part of the public interface of the object. The public interface makes no guarantees about implementation -- encapsulation is one of the fundamental principles of OOP. It is only supposed to appear from outside that you are getting/setting some internal property of the object. And that is the simplest implementation. However, the value of encapsulation is that it really doesn't have to implemented that way. Or the implementation could change entirely as long that public interface works the same way.
> I would only call something a getter if it explicitly makes reference and effectively exposes an internal field.
I think you're original question is "Why would anyone use a getter/setter if they could just a public field?" But your definition excludes all the reasons why someone would do it! If getters/setters just exposed internal fields and never anything else then they really serve no purpose.