There are a number of reasons to try to fill out the body of a question with what you know. While a closing a question for not enough research is not a good reason, the mouseover for a down vote reads:
This question does not show any research effort; it is unclear or not useful
By stating all that you know above the nature of the problem that you have, what you've read, and what you believe to be true you are helping yourself avoid a possible down vote and closure as unclear - buecase its not clear what help you actually need.
Mistaken or Invalid Premise
Sometimes when asking a question, it is based on a mistaken premise. People answering the question are not going to be aware of this premise unless it is stated in the question and are likely to answer it working with the correct assumptions on how things work.
Consider a person trying to make a cake and put it in the microwave oven.
How do you preheat a microwave oven?
This is just wrong, there's the mistaken assumption that a microwave oven is an oven and works like a toaster oven or some other type of oven - that they all work under the same principles and you need to preheat the oven to 350 degrees.
Similar misconceptions of how a computer works, or a given aspect of a language VM works is not uncommon. Sometimes these take ferreting out in a comment in the question if we're lucky to fix the question to ask the right question. Other times it doesn't come out until the answers and then the question tends to morph into a different question - this isn't a good thing.
By stating how you think things work from the start, in the question, it is then possible to work to have answers that correct that mistaken premise and show how that corrects the mental model for how the overall system works and answers the real question.
Repeating what you already know
It can be difficult to judge the level of the person asking a question. Its only text, we don't know if you are a senior programmer, or junior programmer or architect or student or CIO and thus don't know if we should target the answer at the senior programmer or CIO level. Ok, you didn't laugh at that ordering... sorry.
If you were to ask "I don't know why
i++ is allowed in Java when it already has
One answer is "because it is specified in the standards that way" and that is a perfectly correct answer.
However, if the question was "I was reading the JLS section 15.4.2-3 and wondered why this was added when
+= is already present in the language" this becomes a very different question that saying "this is the specification" won't answer.
By stating what you already know, you haven't had anyone spend time repeating back what you already know - wasting both your time and theirs.
Answering far too above the level of the asker
Sometimes the simple questions are very deep when you get into them. I urge you to watch this classic Feynman interview where Feynman points out the difficulty of answering the question - that if you don't understand the question you are asking you may not be able to understand the answer.
You have to know what it is that you're permitted to understand and allow to be understood and known, and what it is you're not. You'll notice, in this example, that the more I ask why, the deeper a thing is, the more interesting it gets.
With many questions, especially the deceptively simple ones, the answer to it may be way over the head of the person who is asking it. It would do a disservice to the person asking the question at a intro to programming, freshman college level when the answer to it is one that really is at the graduate level of theory or senior programmer level of design.
Why can't I match html with a regular expression
The answer becomes one of the Chomsky hierarchy and the pumping lemma and and an understanding of what a NDFA is...
While the question is likely to be too broad to answer at the level, it does allow someone to identify that from the start and work to narrow down the question to something that can be answered in a single Stack Exchange question.