Your example, deduplicating the two functions into one, illustrates an interesting point, although I'd prefer still having the two specialized functions there:

    def set_deadline(deadline):
      if deadline <= datetime.now():
        raise ValueError("Date must be in the future")
    
    def set_task_deadline(task_deadline):
      set_deadline(task_deadline)

    def set_payment_deadline(payment_deadline):
      set_deadline(payment_deadline)

    set_task_deadline(datetime(2024, 3, 12))
    set_payment_deadline(datetime(2024, 3, 18))

You lose absolutely nothing. If you later want to handle the two cases differently, most IDEs allow you to inline the set_deadline method in a single key stroke.

So the argument from the article...

> Applying DRY principles too rigidly leads to premature abstractions that make future changes more complex than necessary.

...does not apply to this example.

There clearly are kinds of DRY code that are less easy to reverse. Maybe we should strive for DRY code that can be easily transformed into WET (Write Everything Twice) code.

(Although I haven't worked with LISPs, macros seem to provide a means of abstraction that can be easily undone without risk: just macro-expand them)

In my experience, it can be much harder to transform WET code into DRY code because you need to resolve all those little inconsistencies between once-perfect copies.