... I wonder if once the program is deployed in production, isn't it also valid to simply log a warning and proceed the execution?
Short answer: No.
Every function you write runs in its only tiny little world that only knows about the argument values passed to it. It can only change or reinterpret the intention of those values if it understands the world "outside" of itself better than the code that's actually "out there", passing those dodgy values in. (hint: that's unlikely)
... isn't it best to show some results than no results at all?
"Are there any indications that this nuclear reactor core has gone runaway and is about to start melting its way through the floor? Hmm; this is taking too long; I'll just return 'OK'. "
OK, slightly facetious example, but in this particular case, then yes, it really does matter that you bring back all the right results. It comes down what's considered "good enough"?
Could a method that iterates over a collection, when passed a null value coerce it into an empty collection and effectively skip execution, instead of crashing?
And do what?
A box of chocolates is a set of zero or more confectioneries; given a box and a big enough appetite, you can "iterate" through all of them. How can you do that if you're not even given the box?
Your function has been told to expect a collection but it's been passed nothing. That's a really good time to let an Exception get thrown; that way, the calling code becomes responsible for handling the mess that it just created, passing you bad (missing) data.
Or a method that receives a negative number coerce it into the minimum/maximum applicable value, instead of crashing?
Why would a negative number cause a crash? Perhaps it's an indexer into an Array or List? Unless there's a business reason to allow negative values (and, admittedly, there could be) then here's another good reason to "pass the buck" upwards, back to the calling code, courtesy of another Exception.