I actually totally agree with this, in general. Jens resists doing a lot of error checking because it would make Snap! slower. I think we should not only catch domain errors but provide a stack trace etc. (We do provide metaprogramming tools with which users could program their own stack trace, but that's not much help to the sort of users who routinely make such domain errors.)
The particular case of empty input slots, though, is fraught with policy issues, because we cram a lot of different meanings into an empty slot. This is mostly what I mean about providing a "do what I mean" experience to users' common programming patterns at the cost of hairing up edge cases.
I think you'd be happier if we'd chosen a different notation for "please fill this input slot for me," or not offered that feature at all but instead required explicit formal parameters in all lambda expressions. No question, that'd be a better choice in a professional language for adults. But, for our target users, I proudly stand by the choice we made (my design, so throw any tomatoes at me rather than at Jens).
In Logo, a text-based language, I used "?" to mean "please fill this slot," as in
map [3 * ?] [5 6 7 8]
If ASCII had had a 
character, I would have used that instead, because it looks like a slot waiting to be filled.
Stop me if you've heard me say this before... If you show an eight-year-old "x+4=7, solve for x" you're likely to get a blank stare, but if you show the same kid "+4=7, what number goes in the box?" you're likely to get the correct answer. This nugget of developmental psychology, which is used in pretty much every early math curriculum nowadays, is the reason we do what we do.
But the trouble is that sometimes a cigar empty input is just an empty value. That's the biggest problem about empty slots; they mean something different in a CALL (directly or indirectly via a HOF) from what they mean in other contexts. An additional issue is that we inherit from Scratch the goal of burying the distinction between numbers and strings of digits, and so in particular an empty slot sometimes means 0. Personally I think that's an overly simple choice; if anything, the empty slot in 
should mean 1, not 0. I agree with the idea of treating a string of digits as a number, but that doesn't actually imply treating an empty string as a string of digits.
I would make a distinction between our edge cases and users' edge cases. So, for example, we should give correct behavior when a numeric input slot has an explicit 0 in it, e.g., 
, which should, in my view, give an error message -- although Jens keeps finding reasons why a project might generate that item number on purpose, e.g., looking for the neighbors of an array item.
But I don't want users to have to write explicit code to check for an empty input. In commercial software, which should check for every screwy edge case, the error-checking code comes to swamp the code that actually does the work of a procedure. That's not okay in a teaching language.
is true for any values 
must be true, or 
, or both.
are true, so must be: 
not being a meaningful comparison, it can not be true, with 
being the negation of the latter, so that one must be true, etc.