The HKDF paper answers this question at length. Section 8 in particular seems to be the most relevant.
But perhaps you may find that the explanations are very technical. To help you out a little bit, the general flavor is this: the security of nearly all modern cryptographic algorithms is conjectural—we don't have unconditional proof that they are actually secure, but rather arguments in forms like this:
- Heuristic: "A lot of really good cryptanalysts tried to break the algorithm, but haven't succeeded."
- Conditional proof: "If you can break this algorithm, then you can break this simpler building block that we believe is secure."
The difference between your proposed uses of SHA-256 and HKDF comes down to HKDF being more careful and pessimistic. We don't have proof that HKDF is more secure than SHA-256 in your application, but the arguments for HKDF's security are better than those for SHA-256 because they rely on fewer and/or weaker untested premises than your use of plain SHA-256 would.
But it's also entirely possible that simple SHA-256 would be secure in this application. Do you want to bet on it? (Lots of systems do, so far successfully.)
So applying this to your comment here:
But I am not stringent about these details, and if simple hash has no serious flaw I will use it because it seems much simpler.
...the thing to remark is that you're looking at the issue backwards—you're proposing to use the simple hash unless somebody can prove to you that it's insecure (which it might not be!). But the way cryptographers look at it is that you shouldn't use the hash function unless you can articulate some good (even if inconclusive) reason why it's secure (e.g., by conjecturing that SHA-256 behaves similarly to a random oracle).