Is there a reason you don't use the $VARIABLE syntax outright? I'm assuming you use $ for something else? It might be something I'd transgress my 'fewest special characters' rule for, though it is mitigated by my 'existing convention' clause...
Traditional Rebol notation with extension:
home: any [
$HOME
$USERPROFILE
]
Or $HOME evaluates to $HOME and get $HOME fetches the value allowing for composition or other construction.
Yes... evaluating a quoted thing drops a quote level and does not affect the binding, while evaluating a $ thing will drop the $ and bind in the "current" context.
>> foo: 1020
>> 'foo
== foo ; unbound
>> $foo
== foo ; bound
>> get 'foo
** PANIC: `foo` is not bound
>> get $foo
== 1020
A lone $ will bind the next item (evaluative) in the current context:
>> x: 10 y: 20
>> collect [keep 'x keep '+ keep 'y]
== [x + y] ; unbound block, unbound items
>> eval collect [keep 'x keep '+ keep 'y]
** PANIC: `x` is not bound
>> eval $ collect [keep 'x keep '+ keep 'y]
== 30
So even though the material inside the block is not bound, the outer block is, so evaluating it can find the WORD!s.
Certainly using the $xxx ("tied") forms to represent environment variables in dialects is an option, and it makes sense for CALL:SHELL etc.
I have used various terms for this as the idea progressed (e.g. "pure virtual binding"). I wanted to emphasize that binding does not deep walk and mutate, but just produces a newly annotated version of the thing--leaving the original as it was in case it had references elsewhere depending on its existing binding. But I've wanted to take back the words "pure" and "virtual" for other purposes so was just going to call it "binding".
Perhaps it should be "conscious binding" (or with a nod to my past life, "intentional binding" 
).
Historical Rebol made unbound material a frightening thing... you were always worried that if you didn't catch the "binding wave" you'd be left with useless code.
Ren-C turns this around by making unbound code a sort of standard currency. If you bind the unbound code at the tip, you get ordinary "scoped" behavior. This makes you less worried when something like COLLECT synthesizes a BLOCK! without binding. A lot of times you specifically don't want binding, because you're building raw material intended to pick up its meaning from the context where you put that material--as opposed to from the place where you were constructing it.
The only person who knows whether your intent is the meaning from where you were building the material, vs. where you're going to put it, is you. 
I know you're not a fan of symbols in code, @rgchris, but hopefully the reasoning of the $ makes sense here... and why quoting doesn't affect binding.
It does introduce strange-seeming subtleties, e.g. '[x + y] is distinct from [x + y] (with the latter often acting the same as $[x + y] under standard evaluation, but due to Rebol's "anything goes" nature there's no rule saying they always act the same--literal inspection is the cheat code for deciding things like "$ means lookup an environment variable, in this situation")
It's not technically necessary to assign $ this behavior. It could be bind here (which, actually will probably be made to work)
>> eval $ collect [keep 'x keep '+ keep 'y]
== 30
>> eval bind here collect [keep 'x keep '+ keep 'y]
== 30
Or we could say that $ is simply here instead of bind here
>> eval bind $ collect [keep 'x keep '+ keep 'y]
== 30
Such things are negotiable, but I think that the desire to ask for something to be bound in the current coding context is frequent enough to make the current choices make sense.
What other Redbols have been doing is a dead end. Not composable, and a bunch of systems code (C-like) propping up a JSON-ish syntax for small narrow apps.
Whether $ is used in this way or not can be debated. But making the distinction between "I'm building code out of parts I know what they mean at the construction site" vs. "I'm plugging in this code in a place that knows what I mean where I put it" is critical.
How far this ends up going is still up in the air (should REDUCE produce an unbound block, or propagate the binding of the input block?) Jury is still out on many of these questions. But the ability of COMPOSE to operate on unbound blocks using the current context by default is now seeming to be the law of the land, also allowing it to operate on strings.