Unlike other technologies like canvas or AJAX where we've been able to create polyfills for older browsers, authors will now have to make an explicit decision between either using CSS variables or supporting all browsers.
As we already have servers, and we even already have preprocessors, it provides no benefit to having it in the client to just bake that in. The result isn't even much less efficient: the variable is not going to be that much smaller than the value itself pasted in.
When you combine the want to support popular older browsers, the fact that not everyone will implement it at all, and the assured compatibility issues between implementations, we will just be running the preprocessor anyway and using it for every browser (again: as there is almost no benefit to using the native implementation). By the time we aren't, there will be some other feature we really want the preprocessor for.
However, being able to have variables in media queries does provide drastically different capabilities as a compile target for our preprocessors. To simulate having variables in media queries requires preprocessors to fork entire rules with each of the different possible media query expansions for the variable. This is an actual (albeit not gigantic) benefit that will allow users to download smaller CSS files if the server detects they can handle it.
Therefore, I would look at this more like a CPU that added a new instruction that cannot be implemented as a macro-expansion in an assembler, but for compilers of high-level languages that are capable of detecting support for it, allows much faster or smaller execution when available.
More directly, though, things that can be done by a preprocessor are, by their very nature, less attractive for us to work on. Syntax improvements are nice, and can justify their existence in the core language, but more important to us in the CSSWG is adding functionality that can't be achieved any other way, or not without a lot of painful hacking.
I'd rather let a thousand flowers bloom on the syntax side while I spend my limited time adding new features.
That cascade depends on the structure of the document, not just the CSS. For instance, consider the following (contrived) example:
:root { var-accent: black; }
.someclass > :first-child { var-accent: blue; }
.otherclass { background-color: var(accent); }
.anotherclass :first-letter { color: var(accent); }
.otherclass { background-color: black; }
.anotherclass :first-letter { color: black; }
.someclass > :first-child .otherclass { background-color: blue; }
.someclass > :first-child .anotherclass :first-letter { color: blue; }
> On the other hand, if you can really edit variable values with Javascript then that would be client-side only, although I haven't seen anything that says you _can_ do that - for all we know Javascript may only allow getting/setting of the evaluated value, not the variable expression itself.
The CSS Variables spec talks about dynamic variable updates via scripting.
div { var-color: red; }
p { var-color: blue; }
section a { color: var(color); }