With only a few exceptions (such as sharing an API or DSL and thus introducing backwards/forwards compatibility issues) it is no more expensive to introduce the abstraction later than it is to introduce it today.
It is easy to introduce overly restrictive abstractions (where you'll need to later work around them) or overly general abstractions (where you'll have difficulty reasoning about or optimizing the resulting program). By delaying abstraction, you can gain a better idea of what you need.
Developers historically have a difficult time grasping simple, powerful abstractions (such as monads, applicatives, monad transformers, arrows, rings, semigroups, monoids, fields) before they, personally, have used multiple examples and seen how the operations and principles broadly apply. There is often an EurekaMoment. In a long-lived project, you cannot assume that maintenance developers will grok abstractions that are much higher level than normally offered by the language and existing standards.
Not all languages are abstraction friendly. Many will make you pay through the nose (in terms of time or space) for each abstraction as a LayerOfIndirection. Many languages fail to adequately support developers in identifying and specializing instances based on context or type.
Parametric abstraction often introduces syntactic overheads that a more concrete implementation might lack. Developers rarely wish to deal with these overheads unless they're getting something out of them, which means having at least two instances.