Still, conventions matter. If you're reading C code, and you see "for (i=0; i<N; i++) { ...", you know what it means, but "for (i=0; N>i; i++) { ..." probably makes you double-take, even though it's equivalent.
If your project's code standard can include testing for (constant == variable), do it, but the impact on readability shouldn't be ignored. (I agree that it's ultimately a language problem.)
Actually, no. Many languages implement == as a operation on the object itself, i.e. invokes a method named == on the object on the left side of the statement. If the things you are comparing are not the same class, then == is very much a directed relation. I agree that logically it might not be, but in many implementations, it actually is.
When it's that kind of comparison, that's an argument for putting the constant on the left. Then you'll know you're getting the kind of equality method defined for the constant (which is more typically what you want).
It's only personal preference that leads you to say that, and in this case, for the reasons cited above, it is deeply suboptimal personal preference.
This is a case of Diax's Rake at work.