On this aesthetic choice, I lean pretty strongly the opposite way.
It's good to consider "top of the page" issues, and having a nice-looking way to import libraries seems good to me:
import @library
Perhaps even putting in versions as @ paths:
import @library/1.1.3
Something possible when sigils don't vanish under evaluation is they can eliminate the need for a block, while still giving a signal to the callee that you passed what you meant intentionally. When IMPORT has to take WORD! and PATH! in its type signature it can't tell the difference if you'd just said import 'library vs import @library if the sigil vanished. I don't really want that axis of flexibility in this case.
Swapping out the behaviors to import $library with the $ being sticky, I don't care for as much.
But also, I'm partial to @ meaning "next thing literally", and it's used extensively in the API. $ doesn't feel as good to me for that.
rebElide("append word-list", rebQ(word)); // verbosity I'd often like to avoid
rebElide("append word-list @", word); // I've liked this since it was instituted
rebElide("append word-list $", word); // don't really like this for the purpose
The idea of $ having "something to do with variables" is fairly common, and can be suggested with a name (VAR-WORD!). And I think this jibes:
>> var: 1020
>> get 'var ; receives `var` plain WORD!, unbound
** Error: var is not bound to a context
>> get $var ; receives `var` plain WORD!, bound
== 1020
The concept of a free $ being a binding operator synonym for in [] (or in PARSE serving the role of what I called *in*) feels good to me. Now that people are being forced to confront binding more directly in their everyday programming (when doing anything interesting) it makes sense to be able to do it succinctly.
(Also, single-arity functions can be optimized as intrinsics, for what that's worth. I haven't yet decided if I want to make things like $ and @ their own datatypes that can't be overridden in the evaluator... but now that we can have more datatypes, I might go that direction as well...)