I have to agree with both sides.
As somebody that asks questions now and then, I know that I sometimes intentionally leave out the context of what I am trying to do, sometimes I will want to know if what I am thinking to do is possible, and sometimes I'm really looking for a solution using the tools I name, because boss/company/coding standards say that it has to be done with them, even if you/I/rest of the community knows that it can be better done with other tools. The problem is that usually the questioner knows all this, but forgets to tell his audience: "I have been told to do X with product Y ... *insert question here*." At these times I am also frustrated when all I get is answers to the tune of "You dont." "You shouldnt" "Use product Z instead".. (I hear a *lot* of these on some chat channels when people ask stuff like 'How do I do XYZ in Windows' and 90% of the answers are 'Use linux' - What sort of answer is that? These people make me mad...)

So, when answering such questions, it is, as you say, a good idea to try and find out the reason for doing things that way, just answering 'This question doesnt belong to this product', or simliar, is not good enough, in my opinion. One also has to say why.
The response of the questioner is equally too short, 'because I need to' is not helping anyone answer the question.

In short, if I'm confronted with such a question, where I think the questioner is asking the wrong question, then I do one of two things. Either, answer to the effect of 'You could probably do that like this *psuedo-code*, but you'll eventually find out that its better to do/use XYZ', or, I don't answer at all, since I don't have an answer that fits the question. That may be chicken, but either somone else will, or the questioner may try out for him/herself and figure out that that wasn't what they wanted.

C.