Following the OCP should always be one of the goals of an OOP programmer. Ignoring this principle erodes how useful it is to decompose into objects.
It is exceptionally lazy to think, "Well if they want to react to change they can just rewrite it".
OCP asks you to favor a design that permits change by adding new code rather than changing old code.
The structural mechanisms for this can as complex as a design pattern or as simple as introducing a variable. Abstraction works best when you can't see the details you're using.
The most telling problem is when you see fit to separate one idea from another by putting them in different objects yet one KNOWS exactly which implementation of the other it's talking to. Doing this not only violates OCP but it means you typed up an extra class for no good reason. If you separate ideas into different objects they should not hold each other in a death grip.
However, change is difficult to predict. Yagni teaches us not to create things that might be useful, only things that are useful today.
Rather then predict the future, be conservative when you assume something will be stable. Our high level abstractions, our interfaces, really hurt us when they change. Keep what they assume to be stable to a minimum. Push what you're not sure of down to lower levels. Break them up to keep their vulnerability to change footprint small. Let them serve only one master.
Do this, and following OCP shouldn't be too dramatically different. If, however, you go nuts slapping interfaces on every object and refuse to call anything that isn't polymorphic, well you're giving us OOP coders a bad name.
The best advice you could apply here was actually about when to react to a DRY violation. You are far more likely to decompose correctly the second time you repeat yourself then you are the first time. So maybe don't be so quick to react.
This wisdom should temper how quick you are to predict change. Unit tests help us see how we could change implementation details. While this is a good structural exercise unit tests aren't production code. Be careful thinking they show you how things will change.
But you should feel bad every time you add a feature or fix a bug by changing existing code. Even if you don't actually have independent external clients it is really nice when you can support large swaths of your code as if it were.
Remember, these principles are not going to help you get your code to work any faster. They help you keep your code working once it does. Therefor you wont find out if you're wasting your time putting effort into following them until changes start coming in. If you want to practice applying them then you can't just code to a fixed specification. You have to code to a changing specification that surprises you.
A conservative way to apply these principles is to add complexity in reaction to change rather than in anticipation. When I take this tract I'll forgive myself for having to change existing code in a module once, maybe twice. After that it's time to see about stopping that from happening again.
Otherwise we might as well go back to procedural programming because even it can deal with change if you're willing to rewrite every time.