It gives a uniform interface (the run method) for each step. You can also, then, encapsulate more logic around that particular step if it needs more than just a single run function or some other stateful component.
Local variables inside a function are very much encapsulated.
Unless you need to keep state between two distinct actions on the same object, but in that case a single run() entry point will not be sufficient anyway.
Inheritance can be replaced by just calling a common function.
There are many “what if” here, which will likely never happen and until they do it’s premature abstraction. Most likely some other abstraction is needed by the time script grows.
For glue code scripts like this you usually don't end up using encapsulation and inheritance or any other fancy OOP design patterns. It's usually grungy IO-bound procedural code, the sort of thing you'd write in bash if bash weren't terrible for long scripts. Don't burden it with premature abstractions. If you end up needing a class, just write the class later.
It's important to remember that YAGNI is a guideline not a rule. If someone spends 10-minutes thinking about the future instead of writing code immediately, and they realize a need that introduces some extra upfront effort but reduces longterm maintenance (fewer changes in the future because it already matches the desired structure), then YAGNI doesn't apply. For standard work, this is a pretty common situation to find yourself in: Recognizing that you've done X before and it led to a particular structure, so when doing X' start with the final structure instead of insisting on 100 extra refactors along the way.
Some great discussion and insights here thanks everyone.
My continued thoughts: since this is a framework for trying to reduce cognitive load, I'm now thinking a pragmatic approach would be to try it out a few times, either as a set of function steps or a set of class steps and see whether one approach falls out as a preferable pattern to default too.
Thinking about it, I can see why classes might be a reasonable default, if you don't need the state, it doesn't matter, if you do, you might be tempted to refactor the script which I think detracts from the goal of this framework.
If anyone is using this, in python, would be interesting to hear their experience.