Cause even the simplest "app" that a usual user is familiar with is much less of a "box" and more of a "house" (in scope). If you tell users to "build a box" they will often say "what is a box?" or "why do I care about a box?" and they'll often disengage at that point. Woodshop starts with "before you can build a box, you must learn the tools" because the students already know what a box is, they probably already know what "wood" is, they understand that "there are tools, such as saws and drills and hammers" even if they don't understand necessarily how to correctly use those tools. Meanwhile in beginner programming, students have so little context that you almost have to start with "here's the concept of vision and touch".

So to keep students focused on something they understand, we don't focus on the tools (at first), we focus on the outcome, with the tools merely as a means to an end, and mostly we give the students "rote procedures" that they must carry out exactly in order to get something that they do understand. Later, once they've begun to become aware of what even exists, what the "box" of the programming world even is, that there are tools for doing different things, what those tools are, etc. Then we start showing them how to use things.

As I mentioned elsewhere here, at university in the first undergraduate computer course we started out with a unix+emacs intro. It sounds unreasonable to me to just start out asking kids to write code without first showing them the tools they need?