TL;DR - there's no value in discoverable (hypermedia) APIs short of some generic API browser that end users don't really want.
* It's self-documenting. Client developers can find all the endpoints just by clicking around (instead of reading mountains of docs).
* Client apps don't need to keep a list of hard-coded urls for random access, removing one of the most brittle parts of client apps (they should know about rels of course, but those end up being easier to keep track of).
Once you actually use an API like this, other APIs feel like they're in the stone age and how to do things with them seems like a continual guessing game. And it's still simple as hell -- remember it's just json with links. It's not like that requires a lot of extra effort.
Not sure about other languages, but most of the client apps I make don't use hardcoded urls - they use a base API url, and then modifications for specific resources. The RestSharp library for C# is a great example of how this works, and even in javascript it's not hard to refactor things so they use a base url and append path & parameters based on the models you're working with.
I'm not arguing the simplicity of it, although it would be more simple to implement if we agreed on a standard like in the original article. I'm just arguing the value.
> I think the original idea behind discoverability was that you could have a “RESTful client” that could in theory work with any REST service that implemented discoverability.
Your analysis of that conclusion makes sense (a generic API browser is not very useful), but why did you think that's "the original idea behind discoverability"?
The BitNative article you link to gives the reason that is usually cited for using hypermedia:
> This allows the API to be highly evolvable because it avoids creating a coupling between the client and the server.
Even more important IMO is that it makes it easier for the many different parties to serve the same API.
Think RSS: clients and servers are decoupled.