It is rarely the case, that problem domain is completely new, so abstractions are premature. Even if you are working in a very innovative startup, it's only core domain, which may require some exploration and there is a risk of pivoting. For auxiliary domains the solution is usually not only known, but many times there exists a series of established solutions. In my experience many things can be predicted. We need to make sure we do decisions late and try to always keep possibilities open. This is most important beyond throw-away prototypes.

Another point is that good abstractions remove code, not add it. Interesting, is that I've came across the same thoughts from a pioneer of computing Gerald Sussman: https://mitpress.ublish.com/ebook/software-design-for-flexibility-preview/12618/C1 (there was also a video touching the same topic briefly https://www.youtube.com/watch?v=O3tVctB_VSU with a catchy name of "We Really Don't Know How to Compute!")