So I decided to do a little bit of experimenting to see what would break if @foo was retaken for iterator functionality.
I got the system to boot pretty quickly, so I could inventory what all had to change (or probably should change, even if it doesn't technically have to).
In PARSE I'd been using @var to mean "match literally", and that doesn't have to change... if for some reason you were using an iterator to iterate rules, you could say inline (@rule-gen) ... and if you wanted to literally match something that was in an iterator you could say @(@rule-gen).
This is pretty consistent with dialecting just generally speaking... if your dialect is doing something different with a part in the box than what EVAL does, your dialect should offer some functionality based on GROUP! to shift into eval to get that behavior back if you need it. 
A little bit harder to cope with is the loss of the @var in DELIMIT to mean "mold". That's tougher because DELIMIT is actually doing an eval on each step, so you're still in the "eval dialect" as it were. You can't really take away iterators there if that's what it does elsewhere.
Similiarly, print @var was a shortcut for print mold var
One might be able to argue that since DELIMIT can't heed bindings, there's no particularly good reason why $var couldn't mean "variable as-is".
If that were the case, then the same could be true in PARSE:
>> block: [two "a"]
>> parse "aaaaaa" [tally block]
== 3
>> parse [[two "a"] [two "a"]] [tally $block]
== 2
Though this is competitive with some of my thoughts about using $ for meanings related to binding in PARSE. 
Iterators Seem Compelling Enough To Rock The Boat, But...
I think the best plan before changing the world is to leave things as they are--e.g. @var meaning MOLD in DELIMIT and "as is" in PARSE.
Do some tests, see how iterators work out, and if we like them as much as we think we might.
Then assess the impacts on @ use after that.