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.
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.