These abstractions become a toolset for creating a program that naturally evolves as new goals and constraints are introduced. It also allows other engineers to understand your code at a high level without reading it from top to bottom.

If your code ever has the possibility of changing, your early wins by having no abstraction are quickly paid for, with interest, as you immediately find yourself refactoring to a higher abstraction in order to reason about higher-order concepts.

In this case, the abstraction is the simplicity, for the same reason that when I submit this comment, I don't have to include a dictionary or a definition of every single word I use. There is a reason that experienced programmers reach for abstractions from the beginning, experience has taught them the benefits of doing so.

The mark of an expert is knowing the appropriate level of abstraction for each task, and when to apply specific abstractions. This is also why abstractions can sometimes feel clumsy and indirect to less experienced engineers.

Haven’t seen even something like opinionated frameworks work well with their initial abstractions.

Even file interfaces in most programming languages don’t come with pipelining. Most are leaky abstraction.

Most abstractions also deal with 1 thing instead of N things. There’s no popular http server that supports batch request processing.

Async-await is a plague of an abstraction.

Abstracting something like trivial if statements is not a problem. The best transaction of all, passing a function to a function is underused.