Don't bother watching the video, it's an extended form blog that can be summarized in a few sentences and I regret wasting 15 minutes watching it at 2x speed. The relevant part for what GP seems to be pointing at:
> Don't use a class that wraps one method (or one method and init).
It's irrelevant to this particular blog article because while the classes start that way, they are expected to grow (if they don't, they probably don't need to be steps in your procedures and you can delete them). The author gives each class the same run method as an interface so the steps can be moved around into other procedures more easily (config with class instantiation, execute with a call to run).
The speaker's point is generally valid, but like all advice should be considered in context and not taken as a thing to do (or not do) all the time.
Is it irrelevant to the code in question? In my career I've run into so much code that is over engineered for a potential future use case, that has just caused so much pain and suffering in the meantime, often that future use case never happens. And to quote another buddy of mine, Raymond, "stop committing atrocities". :-)
It is irrelevant in this particular case because the script is supposed to eventually get more integrated, to become a do-something script - and then you do not want to change the main function (which by then becomes an ordered list) too much, and work within the individual classes.
So why not just use functions directly? Well, sometimes things are too complicated to be put in a Clean-Code-compliant function, and standardisation means less maintenance / and less rewriting if it turns out what you considered function-simple ... isn't.
Yeah, I think if you are the choir, this is just going to be preaching. But, if you're an inexperienced developer and lean towards adding layers of abstraction, this might be useful. In fact, I just recommended this to a team of 2 developers to watch and they found it quite valuable. They are experienced developers, but one of them leans strictly to procedural code, and the other leans toward object oriented, and they were struggling. This worked as a conversation point to talk about where it was appropriate to lean OO.
