I prefer to think of cryptography as infrastructure. We should strive to develop infrastructure that minimizes the number of usage caveats. It's not cryptography's job to define what are "meaningful" messages in your application. Can you look at a specific collision $m_1, m_2$ and say with certainty that no application of a hash function will ever assign meaning to these $m_1$ and $m_2$?
Which hash function would you rather use, one with a guarantee "it's hard to find any collisions" or one with a guarantee "it's hard to find a collision, except sometimes among strings which are JPGs of gerbils and gzip files of Shakespeare"? I would not want to drive a car with a warning sticker that said "car may explode if you are driving 88.1 mph with the left turn signal on and the radio tuned to 88.1 FM", even if that warning was correctly narrow and I would never do those 3 things at the same time.
That's why cryptographic security definitions consider a collision to be any two messages that satisfy $H(x_1) = H(x_2)$, a signature forgery on any message is an attack, encryptions of any plaintext should look indistinguishable, etc. If you want your cryptography to be used, make sure you strive for a security guarantee that puts everyone at ease.
A second practical reason to be concerned about an "unstructured" collision in $H$, is that when one is found, it is often a matter of time before the techniques are extended to find "structured" collisions. For example, finding structured collisions in a random function (using the classic Yuval collision attack) is approximately the same difficulty as finding unstructured collisions (using standard brute force and birthday bound).