In my animation system, I had a laser beam projecting from a fixed point to a movable point in space. There are also sprites which travel up and down the beam.

Moving the beam endpoint required an animation to bring the width to 0, change the endpoint, then ramp the beam width back up. The sprites each have their own animation in different conditions, and moving them along the beam is another animation.

The real key for me was the sprites. I built a class which takes in the start and end points of the beam and an update method. Once you start the sprite up, you just have to poke it every frame with the time delta and it manages all of its own animations.

Likewise, the laser itself was an object that managed its own animations and the sprites related to it.

This resulted in a bunch of objects with just a little code in them. But because the concerns are separated, it results in less code overall than it would take to manage everything all at once.

Is this the best, or even a good way to do this? Probably not, but it was a very beautiful solution in the moment

Nah, none of what you described (encapsulation and separation of concerns) is specific to OOP, you could do that with FP or imperatively with plain structs and functions. It's more like you are starting finally understand how to program in the large.

I'm not completely against OOP, but written code that strictly adheres to this paradigm tends to be more convoluted than necessary.