That's true, and I'm sure it can be confusing, especially for beginners.
I like it the way it is though. In cases where you have decided to change the code to work on arrays, this allows you to start such a process by changing the mode of the equal sign - then change the inputs. It does not enforce you to do it the other way around. I like that kind of freedom when I'm coding.
This is deliberate. In general, LabVIEW tries to not insist on the order in which you change your code. This is not a universal thing, but it is something we try to adhere to when possible. Just because you are wired with scalars at the moment does not mean that you're going to change to arrays as your next action after changing the comparison mode. It depends on the order of operations in your head. When we combined that use case with the use case of wanting to retain behaviors of nodes through copy/paste and the use case of avoiding resetting to a "compare elements" just because type prop happened to send a scalar down the wire while you were doing some upstream edit, we decided that the option should always be available.
Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Comparison-mode/idc-p/2975641#M28972