The reason why most language designers don't like constructs like starting variables with special chars is that most language designers want to minimize the amount of repetitive "stuff" that is required of the programmer, so long as the compiler / interpreter can figure it out. So, to many language designers, the code:
var x = new Something()
has less cruft than:
Something x = new Something();
("Why repeat the type specification? The compiler can infer it. Why have the semicolon? The compiler can figure it out.")
which in turn has less cruft than:
Something $x = new Something();
("Why make every variable start with a '$'? The compiler knows that the token at that position must be a variable name")
This design aesthetic is something that most language designers would probably agree with in principal, but of course beauty is in the eye of the beholder. The "inferred semicolons" in JavaScript, for instance, can lead to surprising behavior.
Your opinion that there's value in quickly identifying variables by their $
is perfectly valid, but another person might say "Well, the only real semantic benefit is that you can have variables named similarly to keywords ($if
) and that's a dubious benefit." In the specific case of refactoring, in languages with tighter type semantics, many refactorings can actually be done in not just a quick, but "guaranteed safe" way, since the refactoring is not being done on "just some string" but on a very specific element in the parse tree.