My issue with this is that a simple design can set you up for failure if you don’t foresee and account for future requirements.

Every abstraction adds some complexity. So maybe the PoC skips all abstractions. Then we need to add a variant to something. Well, a single if/else is simpler than an abstract base class with two concrete implementations. Adding the 3rd as another if clause is simpler than refactoring all of them to an ABC structure. And so on.

“Simple” is relative. Investing in a little complexity now can save your ass later. Weighing this decision takes skill and experience

I think what matters more than the abstract class vs if statement dichotomy, is how well something maps the problem domain/data structures and flows.

Sure maybe its fast to write that simple if statement, but if it doesn't capture the deeper problem you'll just keep running head first into edge cases - whereas if you're modelling the problem in a good way it comes as a natural extension/interaction in the code with very little tweaking _and_ it covers all edge cases in a clean way.

I’m aware I’m about to be “that guy”, but I really like how Rich Hickey’s “Simple Made Easy” clarifies simplicity here. In that model, what you’re describing is easy, not simple.