This model for a position statement can be helpful in very early development. Having a statement early, even before the solution exists or is even fully understood, will be a competitive advantage. Some of the other examples in comments (which are great by the way) require having a better understanding of what you are building.
> In terms of what comes first, product or positioning, Jackson suggests that the two should grow up side-by-side.
Using this as a model gives you a first cut, which you can later refine and shape into something even better.
It doesn’t make sense for generalized scripts that automate routine tasks. But for some maintenance, build, test, or deploy scripts that only ever perform a specialized job from a single location, it could be handy. I appreciate that Maciej provided it. Always easier to remove it than have to go find it yourself in the odd script you might need it.
Not unlike Goldilocks sampling the bears’ home, what is just right, is often a matter of perspective.
A developers education, experience, and domain all impact how different abstractions are perceived. Sometimes having an abstraction can reduce cognitive load. Think of the configure vs convention arguments for frameworks. Knowing how to implement simple functionality the “right way” (within the paradigm of that abstraction) can make building software easier especially when collaborating with others.
I personally find consistency more valuable than having the perfect level of abstraction. Consistency, even if slightly more or less verbose than I might otherwise choose, means I spend less time thinking about the abstraction itself. It allows me to focus on the problem domain, which is where customer value exists. It has the added benefit of simplifying collaboration with others who are also familiar with the abstraction.