The high-level answer is that construction is vulnerable to practical attacks based on hash function weaknesses, but that it's significantly harder to attack than secret-prefix MAC functions. But once you understand how secret-prefix MACs are broken, you quickly see the logic behind HMAC.
For example, if you already happen to know a collision hash(m1)=hash(m2), where m1 and m2 have full block size, then you also get a collision hash(m1|key)=hash(m2|key), just as explained in the article. So, one could forge messages, which should clearly be counted as a weakness, even if it assumes knowledge of a collision.
Well, if you have an internal collision hash(m1)=hash(m2) and both messages m1 and m2 are of the same size, then it seems that one would also get hash(m1|key|size) = hash(m2|key|size). So, I cannot really see how appending the size will help.
(All subject to optimistic assumptions about block sizes, etc.)
Please substantiate. An attacker knowing an internal collision of the hash algorithm for m1 and m2 (of the same size...) can construct HMAC(m2,key) from HMAC(m1,key) without knowing the key?
Relying on the way you happen to combine data, instead of using a function that's designed for authentication and has baked-in a safe way to combine the inputs, is a bad idea. "What if $EDGE_CASE_OF_INAPPROPRIATE_CRYPTO_FUNCTION" is never a good question to ask. Just use the right tools in the first place.
The first reason is because the questioner is looking for an excuse to use something different. In this case, your answer is the right answer.
The second reason is because the questioner wants to learn more about how cryptography works, for educational value. In this case, your answer is not helpful.
