I've noticed this kind of mindset helps with debugging. I use it to eliminate possibilities and to also keep going. The latter is especially important when I think I've already tried all possibilities. It's a constant check that keeps me from thinking it's a problem on the computer's end, instead of a problem on my end. I can think of a number of times when I've been able to solve the bug precisely because I kept the right mindset.

As for the term "meaningless," I think I can see what the researchers are saying. For example, when I first started programming in QBasic, I was trying to modify a game called Gorillas that came with the language. In the game, there are two gorillas that try to destroy each other by throwing exploding bananas. I saw one variable in the code was called 'banana' and thought changing it to 'baby' would make the gorillas throw babies at each other (yes, I was a strange kid). Anyways, that would be an instance of looking for meaning where there isn't any. I ignored the syntactical context of the variable in favor of the semantics of the variable name, though this was more due to me not being familiar with code.

So, the tested students who focus on the syntactical context of variables and keywords will probably be better at understanding programs than those who focus on their understanding of these words' semantics. The problem is not "meaning" itself, but that they are using the wrong frame of reference to derive meaning.

Perhaps a better distinction, then, is objective vs subjective meaning. Those who look for the objective frame of reference to infer meaning will understand programs better. Once they do so, they can analyze programs more semantically. For instance, now that I've been exposed to many languages, I know something called "print," occurring in a certain position on a line, probably outputs textual information somewhere, such as stdout.