My guess is, it has to do with how you handle 1, 2, N. The first time we write something, we write it just for that specific case --- no point overengineering if you don't know you'll need it. (Hence the "YAGNI" advice that is common.)
Now, there are two things that code has to handle. You could put in a simple bit of special-case logic, or a case statement, and move on, OR you could instead spend time, codes, and tests making it robust to handle many different types of input, with a type-specific config system that makes it easy to add new type-specific behavior.
Our predilection on many teams is to skip the middle part, and write robust automation the first time we hit a special exception. ("This used to be about ordering burgers but now we want to also order shakes, and they don't have a cook-time.") It seems like the OP was suggesting that we do a "crappy" good-enough solution to that intermediate phase of complexity, as there's a chance you might not need more than that.
The idea is that you grit your teeth and let code be deduplicated twice (but no more), rather than immediately DRYing up code, so you'll (hopefully) have a better sense of what the common code should look like.
(I personally think it's too hard in practice, as common code can be written sufficiently differently to not be recognizable as common by the Engineers Of Tomorrow).
The first time you implement, the default is to over abstract. The second time even more. By the third, you have a good enough idea of what you need to then build something robust. Each phase is faster.
Second iteration is almost always copy and paste of first with small tweaks. I’d rather that than some kind of conditional.
The best UI almost never fits the most convenient technical solution so we optimize for UI and then technical.
