Interestingly enough, in Python, the minimal, official style guide of PEP 8 actively suggests using properties (the equivalent of the JS getter/setter syntax) for simple things: https://www.python.org/dev/peps/pep-0008/#designing-for-inhe... (See the section that starts with "For simple public data attributes, it is best to expose just the attribute name, without complicated accessor/mutator methods.")
I think in practice this ends up being mostly a function of what's idiomatic in the ecosystem. The most common JS style guide recommends _against_ using getters and setters, so it would be surprising for something in JS to do so. The most common Python style guide recommends _for_ using properties, so the syntactical near-equivalent ends up being something "expected".
> Note 2: Try to keep the functional behavior side-effect free, although side-effects such as caching are generally fine.
Personally, and I'm happy to to be wrong, I can't think of any situation where mutating data in a getter is a good idea... in any language ever. Every single time I've caught myself thinking about it, if I take a step back, what I'm about to do is hot garbage and thankfully my hot-garbage-sense caught on.
I think the context is important here - it's in the "Designing for Inheritance" section. If you're doing that, you're already pretty far in the OO thicket which a lot of Python users prefer to avoid. Actively encouraging properties is not generally a widely held view.
I think in practice this ends up being mostly a function of what's idiomatic in the ecosystem. The most common JS style guide recommends _against_ using getters and setters, so it would be surprising for something in JS to do so. The most common Python style guide recommends _for_ using properties, so the syntactical near-equivalent ends up being something "expected".