I think to assume that someone who disagrees with you "doesn't understand OOP" reeks of hubris.
Not only do I fully understand OOP, I was on the cutting edge of adopting OOP with C++ and Smalltalk when the opportunities presented themselves technically, starting around 1990. I was an "OOP bigot", and since then I've used literally thousands of libraries, frameworks, and classes that others have written as well as written quite a few of my own. I don't need to cite decades of anyone else's experience when I have decades of my own.
In fact, it is because I understand the promises and failings of OOP, that I categorically state that hiding data behind private limits one of the biggest benefits of OOP, and that's code-reuse. Despite what you may have learned in college, OOP does not require the use of the private keyword; you can (and should) use protected and not only be effective implementing OOP, but you can make your code more easily adaptable in the future. Speaking of which...
Assuming you know all the ways your code will be used at design time also reeks of hubris. The fact of the matter is, business and technical objectives change all the time. Java itself was designed to run set-top cable boxes and now it runs everything from enterprise software to mobile phones to bloated cross-platform IDEs. Accept the idea that:
1. You, nor any other programmer is omnipotent.
2. You do not have a crystal ball. If you did, you would have invented Bitcoin in 2008-2009. Heck I guess technically, you could have...
3. Other people, some of them potentially smarter than you, might be "up to the task" of wanting to take your code you've written, and it's useful, apply it in new ways that you'd never considered.
As far as your cited RoundTraffgicBulb reference, what happens if the traffic light happens to be in Japan? Here's a hint for you: those colours aren't Red, Amber and Green. Maybe it's worth thinking of your traffic light implementation as a state machine with event timers and output signals that could control the colors of the light.. Then maybe that state machine could be modified a little bit to function as a light and the output signals could also control drawbridge. Perhaps the "shit desig"n to assume it's always going to be used exactly as you imagine.
Now I happen to agree with you about exposing the set accessor is a reasonable way forward. But what happens if you need to make a bunch of changes that complete in a transaction, or that when some kind of locking occurs? Maybe that traffic light is integrated with a "Walk or Don't Walk" signal and you want to ensure that you enter those states in controlled fashion?
