However, what if the specs were able to capture what is in such human-readable pages (for example https://docs.cloudant.com/)? What if API spec could be automatically derived out of HTML pages? Embed some metadata in HTML page and then we have both cake (human-readable) and eat it (machine-readable)?
We ended up using Swagger, which doesn't solve as many of our problems (having documentation generated from code isn't as robust from a testing POV, particularly when your RESTful API is versioned), but my "perfect" is the enemy of the company's "good" :).
Scrape HTML to swagger: https://github.com/bobby-brennan/scrape-to-swagger
Swagger to HTML docs: https://github.com/lucybot/lucy-console
We also have a commercial version of the latter which you can see at any-api.com
I agree the API provider's primary concern should be Developer Experience, and understand why creating a spec often takes a back seat. But I suspect that soon it will be seen as critical for any production grade API to have a machine readable spec.
I view specs as analogous to unit tests - it doesn't get you closer to a deliverable product, but it makes the development lifecycle much less painful.
And I disagree that formal specifications are intimidating. A formal specification is just code, so if you have trouble understanding something, you can enlist the computer's help. On the other hand, if an informal specification isn't clear to you, you are more or less screwed.
Psychologically, looking at a formal specification is pretty intimidating. How many people do you know who enjoy sitting down with a cup of coffee/tea and their favorite time-worn leather-bound copy of RFC7231?
Most developers I know love getting something to work. They love the feeling of having mastered something to the point that just reading "GET /widgets" is enough for them to go off to curl and implement the rest ad-hoc as they're visually inspecting the JSON and occasionally referring back to the docs.
Creating formal specs is probably the most efficient way to go in a purely computational sense, but reading specs is hard work and it's not especially inviting or rewarding, especially to a class of workers that would much rather jump in, get their hands dirty, and figure it out themselves. It's why developers love frameworks/APIs that just feel simple and familiar. The low cognitive overhead, and low barrier to entry gets you into a wonderfully endorphin-driven flow that's hard to replicate.
Formal specifications are great. But they won't likely get read by people. And people, not machines, are going to drive your profit as a business offering a shiny API.
So should you focus on your formal spec first, or human-readable API documentation? Probably the latter. And good luck convincing the business owners that a spec is a high priority now that you technically have everything covered.