Ren-C now has an ENVIRONMENT!, which you can instantiate under what name you want, so you can alias system.environment as just env in global scope.
At which point, you are comparing to env.HOME (or env."HOME")
I guess I'm still torn on the religion of the URL!. It's a nice trick to have a namespace ("scheme space") that a colon (and slash slash, under current rules) buys you by coming after the scheme, and to implicitly quote it as a literal. That does seem a bargain: you're getting $schemes.name."what/ever" for the low-ish price of name://what/ever, with name kept free in global scope.
While I recognize that value, it's in the context of a system that has to actually do the work. And that work is helped by program structure.
But...I wouldn't have gone after string interpolation if I didn't think the language needed more competence with strings. 
So using tuple access (and the ENVIRONMENT!) you can indeed say get $env.HOME.
There's a kind of expectation-management going on, which seems to constantly be subverted by the interconnected world...that a simple operation will do a simple thing. The idea of something like a GET doing a network access might look to make sense if you say get http://whatever but when it is obscured behind get var that feels dangerous.
Maybe ENVIRONMENT! is already a problem. Should there be limits on what TUPLE! access (hence PICK and GET) is allowed to do, that you trust it only reads variables from inside your program memory, and anything that's "interprocess" needs a LOAD or READ at minimum?