As a counterpoint, I find custom formats to often be nicer than reusing generic ones: atomic values (individual lexemes, primitive types: strings, numbers, etc) tend to have custom formats or semantic restrictions anyway (say, dates, length-limited strings, range-limited numbers, though in some cases numbers are also just restricted strings), so that part is mostly handled from scratch either way. And then there is composition, with JSON--apparently the most popular format now--not having a standard way to encode sum types, so you basically have to hammer those on top. At which point it feels like building on top of a JSON structure instead of building on top of a sequence of characters, but not in a very different way: sometimes it is more helpful in some parts, sometimes adds more clutter than needed. Likewise with XML: it is not uncommon to see something like <my-custom-format>a string in a custom format here, or even a base64-encoded blob</my-custom-format>.
In practice it is easier to use JSON for interfaces, since for someone unfamiliar with parsing it is less work to sort out on the other end, and then you have at least a partially specified structure, the rest can be easier to specify (with JSON schema, for instance), there are readily available libraries and tools to work with it, to do at least some of the parsing without writing a parser. But I think cleaner interfaces can be achieved with custom formats.