Those abstractions become useful and powerful when we look beyond today, and when thinking about this code living for years to come. Some of Tree's feature may benefit from being lazy and might want to leverage ES5/6 features in the future; to maintain compatibility with older environments these abstraction become highly valuable.

The general way I look at attribute vs. properties when developing Base-based classes is on a per-instance vs. class-hierarchy state/config. This combined with thinking towards encapsulating future language features behind the `get/set()` abstraction is what lead me to thinking that these should be attributes.

Sorry I wasn't more clear on my reasoning… leading you to think I was suggesting we add a layer of abstraction for the sake of it.