There are two distinct ideas here.
The first idea is that the format could have types. XML doesn't; XDR and bencoding do. As you are evidently aware, XML Schema adds data types to XML; this is evidently something that many people have found lacking in XML. Moreover, if you have typed data, then if you're using an untyped format, then at some point, you are mapping between typed and untyped forms, and vice versa, in which case you're essentially imposing your own type system. You might as well have a type system in the format to start with.
The second idea is that the format could embed types in the data. XML can't, because it doesn't have types. XDR doesn't, bencoding does. There are many other examples on either side. The tradeoff is simple: formats which don't embed the types can be more compact, but formats which do can do a better job of detecting mistakes. A very common kind of mistake is a format change: you write some data in version N of the format, and read it with version N+M of the format; the more information about type and structure you embed, the better chance you have of detecting this rather than reading garbage. Data with embedded types can also be processed without knowing about its structure (eg you translate bencoded data to JSON without knowing anything about what was in the data; you couldn't do that with XDR), but i suspect this is rarely useful in real life.
So, it's a tradeoff. If the format is for interchange of data between machines in a cluster, where they will all be running the same code, the integrity advantages of embedded types seem largely irrelevant. If it's for interchange of data between different companies, or long-term archival of data from some system, then the integrity advantage could be very valuable.
