If you didn't know, CSS is adding Variables to the language. 

We needed to nail down some arguments about the syntax used, so the CSSWG discussed this yesterday at our face-to-face meeting.
First, let me state this plainly. THE DECISIONS MADE ARE NOT NECESSARILY FINAL. We needed an answer to the questions, so that if nothing else came up, they'd be settled and we'd have a completed spec. However, we can change it if necessary in the future.

The Actual Decisions The CSSWG decided to use properties that look like "var-foo" to define variables, and refer to variables with a function like "var(foo)".
We also agreed to include the fallback argument to the var() function (a value to be used when the referenced var is invalid or undefined), and to defer the parent-var() function to level 2, which we'll start working on concurrently, as we think we'll need more time to suss out features in this space.

What's the Relevance?
Previously (in fact, currently, since I haven't updated the spec yet), there was discussion about using properties that look like "$foo" to define variables, and using "$foo" to refer to vars as well.
(There were also some additional suggestions to use the same structure we decided on, but different prefixes or function names. I'll omit those from this discussion, because they're less interesting/controversial. Most people who don't like the decision we ended on want $foo, not just a different prefix in "var-foo".)

Why Did I Drop $foo?

 I'll start by saying - I totally like the $foo syntax. I am definitely not opposed to it in general. It's in the current spec (until I make edits) because I liked it and wanted it.
However, I recommended we drop it. Why?
Mainly, I think there's more space to explore here. If we use $foo for variables, we'll be unable to use it for future "variable-like" things.
For example, if we do define an alternate form that are more SASS-like (can be used anywhere, but are global; more "macros" than "variables") we'd have to use some other glyph for them. That's suboptimal.
More specifically, if we ever do some sort of "variables" in selectors, we must use a compact form like $foo or something. Anything else is unusable, I believe.
For example, David Baron recently proposed a powerful form of selector variables for discussion. After some thought, I realized that this is exactly identical to SASS's @extend directive, just with a somewhat different, more explicit, syntax.
As another example, fantasai and I have been discussing a proper macro system for CSS; in other words, exactly what SASS's variables currently do. I ert that we'd definitely want a nice short "$foo" or similar syntax for this as well.
However, CSS Variables as written don't have these constraints. I think it's acceptable for them to have a slightly longer form, given the way they're used. (They're not being pushed into a terse microsyntax like Selectors.) As well, they're not "combining" with surrounding context like macros might do, so the functional form is okay.
So, for now, I recommend that we drop the $foo syntax from CSS Variables, and look into the other types of things we can use this syntax for. If we don't find anything that needs this kind of syntax, then we can go back to letting Variables consume this kind of syntax for its own use.
I hope this clears up some of the confusion around my reasoning for this decision. Questions? Let's take them to the comments.