Given that type-checking is more strict now with respect to NULL and TRASH, this does give a possible reasoning for why you might want to use a "void-to-unset" assignment.
Right now if you have a variable which is meant to optionally hold a function value, you don't want to use NULL:
some-hook-that-takes-integer: null ; optionally a function
Because then, if you try to call it with no arguments when it's not set, you get a no-op in todays world:
>> some-hook-that-takes-integer 10
== 10
So you can use either TRASH! or void to "poison" such values, to stop that from happening.
In any case, if you use ^some-hook-that-takes-integer you can get it back as a trash value vs. erroring on access. But TRASH! isn't easy to convert to void--it wasn't meant for it.
So if you wrote:
apply opt ^some-hook-that-takes-integer [10]
You would likely be intending "run the function if it's there, ignore it if it's not". But you'd be OPT-ing a trash, which doesn't give you void today.
Setting the variable to VOID is a better bet:
apply ^some-hook-that-takes-integer [10]