The getter setter logic esp in the java language originates in the bean concept to allow discoverability.
to me the question of value objects vs variable objects is very important. it's along the lines of Mark a value object should be immutable and can have public reads.
As soon as we go for variable objects I kinda differ from his point of view where a getter and setter still should only contain set and get logic to define the communication of change but the idea of having explicit validation logic in a data object .... I would rather prefer validation decorators along the lines of Design By Contract or what mark mentioned with python decorators.
Although I would rather prefer a Validator outside so I can compose the logic. This is a mental design question.
So the main problem of mutation is control of change and public means no control which also makes it harder for the compiler to reason. (depends on the language)
The problem of coupling logic to your data is as always context and polymorphism / subtyping. It's a language specific type-cohesion concepts where in one classification certain rules apply and not in the other.
Which can lead to bloat in the getters / setters. But than lets be real for a second ... it's very unlikely outside an algebraic concept that those problems arise and it really depends on the language concept.
Please do correct me if I am wrong. I can think of some cases where the previous statement isn't valid.
In PHP for example I insist on them for example because I cannot enforce scalar types on fields (yet).
Also the access for the debugger does not work on properties so the loss of 20% performance for function method call deference is a price I am willing to pay to ensure that my code:
although I hate the bloat of getters and setters they are a constraint in this particular language design.
The getter and setter problem solution in dart for example is interesting, if you don't access a property it's private as soon as you do it's public.
I think this also helps the compiler to do certain optimizations since it's based on behaviour.
In an OO approach that is about messaging, mental models and mutation a getter and setter can be perfectly reasonable. It depends heavily on the language, the concept and the goals.
Everything else would be imitation and not understanding and if you only imitate it sounds more like religion than reason :)