I had the same response when reading RESTful Web APIs. I think Leonard Richardson and Mike Amundsen did a great job explaining hypermedia, REST, and surveying today's available media types. Specifically, I enjoyed their insight that we are very used to traversing the web via hypermedia in the form of HTML.
But the strong push for choosing a pre-existing media type seemed off-based, especially the language that states something like "if you're not using one of our media types, then you're committing a grave sin." I don't see anyone using
ALPs, for example.
I think of it as a chicken-and-egg problem. Say Twitter, Facebook, Google, and Salesforce implemented their APIs in a nicely defined media-type, with hypermedia and all. Then it would make sense for everyone to follow suit. But this isn't the case today.
I've tried thinking through how we could use media types like
json.org, Collection+JSON, HAL, Siren, etc, at our company. But it seems that the tooling and community is not there yet to make such a commitment worth it. There are also a lot of unanswered questions (how would you combine two media types in a single API? What happens if I choose Collection+JSON and find it to be insufficiently expressive for future needs). An ad-hoc API (i.e. "fiat standard" in RESTful Web APIs) seems to still be the "safest" way.
I know some companies have successfully used one of these media types.
Balanced, for example, uses
jsonapi.org, I'm sure thanks to the work of Steve Klabnik. But even Balanced builds
their own clients, which makes sense, because the semantics of a money transfer API is different than a to-do app.
At the end, I don't think there is enough real-world evidence to show that it's worth all the effort to go full hypermedia with well-defined media types. And so some of us that are designing APIs go back to what we know best: our nice, safe world of a personal fiat standard.