In general, you should provide the parser with as much information as possible so that it does not have to guess what you mean. In this case, using the = sign with /var makes it clear to the parser, and to you when you later read the script, exactly where the assignment is taking place. The more information the parser has, the more likely the script will work in the way you expect. This applies to the = sign, brackets, and anything else that makes it clear to the parser what you mean.
As the parser supports $+ and [] brackets, which allow you to create dynamic command lines and parameters, this creates all kinds of problems for the parser, since it has to guess how to evaluate a line based on context and the evaluation priority of different parser features.
I would say that allowing /var without an = sign was a bad idea (I cannot remember the context of its implementation). However, it was probably implemented that way so that it would work like /set, which also does not need an equal sign. The = sign support was added later (I think) because of /var support for multiple variable definitions, each of which could have their own assignments leading to ambiguity if an = sign was not used.
Thanks for your comments on this topic everyone.
