When I provide that data (file) to someone I will inform them:
Hey, the file consists of the lengths of rivers in the U.S. Each line of the file contains two fields: the U.S. name of a river and its length. The fields are separated by a tab. The length is expressed in miles as an integer and groups of digits are separated by the comma symbol (such as 1,759).
Without that explanation, the file (data) is useless. But that holds true for an XML file containing the same data and a JSON file containing the same data. One might argue that with XML the tags describe the data, so an accompanying explanation is not needed. But relying on XML tags to explain data is folly (e.g., what if the developer uses generic tags such as <li>, such tags hardly "explain" the data). I would argue, regardless of the data format, there needs to be some accompanying explanation about the data. And if that's the case, then heck, use the simplest possible data format (use the super-simple data format shown above) and take advantage of the plethora of tools available for processing super-simple data formats.
I think that, for data files that are not trivial, using XML or JSON shall be better than using custom plain text files (like the tab delimited file that you've described). The advantages of using XML in such cases, comes from the fact that, if we standardize on schema technology like XSD, we can explain semantics of data items using XSD <annotation> tags for example. Or, we can write semantics of data items, with simple XML comments. Plain text files, like you've suggested, doesn't have any such alternatives. The semantics of data items, for plain text files, mostly have to be written within procedural code of the concerning application.
