Where we do the reading(get) and writing(get) majorly determines how much cost we pay for performance.

setters

A setter function is called every time we write some value.

Now we generally do the writing part that calls the setters in our TypeScript Classes. So they don't get called so often unless there's a set operation, which isn't quite frequent in general.

getters

A getter function is called every time we read some value.

getters are generally called in templates in different data binding syntax like string interpolation({{}}), property binding([---]=""), attribute binding([attr.---]=""), style binding([style.---]="") etc.

Now the catch with this is, every time Angular performs change detection, the getters get called. It's fine as long as there isn't much logic in your getter. But that still leaves a room for newer developers in the team to add logic in there without being aware of the performance hits that it's gonna create.

So in summary, from what I understand, it's okay to have setters. But having getters and it's cost on performance would mainly depend on where those getters are used. If they're used in one of the template binding syntaxes, then it's safe to NOT HAVE THEM IN THE FIRST PLACE. If they're not being used in the template, it's okay to have them.

I've actually written an article and a few answers on various StackOverflow Threads that you might want to check out as well. So I'm adding them as a list below:

1. Angular: Prevent DomSanizer from updating on DOM Events

2. Angular performance: ngStyle recalculates on each click on random input

3. Angular 7 ,Reactive Form slow response when has large data

4. Angular Performance: DOM Event causes unnecessary function calls

5. I changed my implementation of an EXTREMELY deeply nested Angular Reactive Form and you won’t believe what happened 🤯

Hope this gives you some perspective. :)

avoid getters specifically if possible. Getters have a negative effect on change detection. In order to know whether the view should be updated, Angular needs to access the new value, compare it with the old one and make the decision on whether the view should be updated. For this reason, the value is compared and updated on every change detection cycle. This can cause performance issues and circumvents certain configurations like OnPush. If for some reason you need to transform data when an @Input() is changed in a component a setter is fine for example.

value;
@Input('myValue') set myValue(v) {
 transformValue(v);
}
transformValue(v) {
...*sometransform*
this.value = transforrmedValue
}

in this example, a setter is placed on the Input and the value is transformed every time a new myValue is pushed to the component. However, if a getter is introduced the component will check the getter every time change detection cycles anyway. You could also use other things like pipes or ngOnChange instead of setters.

UPDATE

as long as your component is using ChangedetectionStategy.OnPush now using a getter is fine but still avoid it if you are not using OnPush

This is part opinion, part the requirements of your application. It is certainly not bad to use getters and setters. But I would also use them with discretion and in most cases getters and setters may be unnecessary.

In the example code you provide, there is no reason to use a getter and setter. You are correct in that it can help when doing some sort of validation check or when something else in contingent upon the value being set, etc. For example, maybe you need to call some function when an @Input() property changes value, this can be an easy way to accomplish that. But in many cases, this is probably not a requirement for every variable/input in your application.

Hope this helps.