The rationale is the same as that for an abstract data type. You don't need to know how a class structures its properties and directly coupling to a representation can burden future maintenance. This very rarely comes up, but when it does it is nice to change a getter instead of tracking down all the locations where it was directly coupled to the representation. It isn't at all obvious when you are writing a class whether future maintenance will need to change the representation or not.

This isn't as much a big deal in python, for example, where you can @property your getter and setter. In that way you can easily migrate existing code from direct data structure coupling to indirect/computed access.

.. except when manipulating proxy-ed objects, like Spring beans or ORM detached entities. The object you're calling the setter on is not the object (struct) holding the field..

I know, yet another idea thrown into the concepts cocktail.. (not saying these are correct justifications for the getter/setter pollution, just reasons why you find them everywhere in the wild)