Two scenarios in which this might get used: 1. I expect a variable to contain a collection or nil (signifying that there is nothing to be enumerated); 2. I expect "any" kind of object to arrive in that variable.
If my expectation in scenario 1 is not met due to a programming error, I would have previously noticed it early because of the ensuing MessageNotUnderstood: isEmptyOrNil. Not any more with this addition. Instead I will just get MessageNotUnderstood: do:, for example, when I try to use this non-Collection like a Collection. This might happen at a much later time if the object gets stored somewhere due to "not being empty".
In scenario 2, what do I learn about my object if this answers false? That it is not nil and not an empty collection; there is still nothing that I can safely send to this kind of object except messages understood by all objects. To send the latter, I wouldn't have needed to run this test first. If the object is in fact empty or nil, I probably wouldn't keep it or send any further messages to it either because there is nothing in it.
Hence I'm wondering when this would ever be a useful response by a non-Collection. And whether it is worth hiding or delaying some errors, as explained above.