Imagine you have a function that takes one BLOCK! and emits the data from the block to a file by default. But optionally there's another filename into which the data will be put. The conventional way to do optional arguments in Rebol is via refinements:
emit [x y z] emit/into [x y z] %foo.txt
The usual suggestion to someone who finds this kind of thing cumbersome might be to consider taking a dialected block:
emit [x y z] emit [%foo.txt [x y z]]
And if you're lucky enough to know that the slot where X lives can't be a FILE!, you might be tempted to eliminate the nested block. But you may not be lucky...and if the block lives in a variable instead of a literal, introducing a new level of block suppresses evaluation and causes you all kinds of grief. You start needing to COMPOSE or REDUCE, and this kind of problem comes up a lot.
With variadics we now have another possibility:
emit [x y z] emit %foo.txt [x y z]
At the interface level, rather than implementing this using a single VARARGS! it could be supported more cleanly by marking parameters as
emit: function [file [<skip> file!] block [block!]] [...]
This could tell the evaluator that if it can't match the type of the first argument, then just set it to void and keep going. An upside to this is that it would mean people using APPLY wouldn't have to jump any particular hoops to build a VARARGS!, and could supply parameters as normal.
Is permitting this a good idea? Well, the cat's out of the bag as variadics are permitted now, and I think variadics have many justifiable applications. The real worry is if you start writing things like:
emit x blah-blah
...and the reader can't be confident if x is a FILE! or a BLOCK!. Of course, if you don't know if x is a FUNCTION! or a BLOCK! you've always had a similar amount of trouble. You also get in a bit of trouble the day you decide that first argument to
emit can be either a FILE! or a BLOCK!, still taking a BLOCK! as the second argument. But changing function interfaces always influences callsites, this is just taking it further. I'd argue it's just how Rebol is.
Now this doesn't mean it's a good idea to use for exposing core functionality. But if one is scribbling out a quick-and-dirty script, this freedom may be all part of the deep lake.