There are a lot of benefits for the API producer in terms of tooling and the ecosystem.
But that tooling also helps the consumer. Look at all the tools listed here: https://openapi.tools/ Those that would be helpful to me as a consumer of an API are:
* Documentation
* Learning
* Mock servers (for testing)
* Some of the tools under misc
* SDK Generators. Most people don't want to consume an API using REST, they want to use their fav language to do so
I asked in a slack full of developer relations folks about alternatives to OpenAPI for defining REST APIs and didn't hear any good alternatives.SlateDocs looks really nice, though. As sibling comments have pointed out, you can have both.
Mostly familiarity.
The OpenAPI spec and the Swagger tools are something that a _lot_ of devs are familiar with, and they integrate well with lots of other tools (We have OpenAPI docs embedded in out Confluence/Jira workflow).
That SlateDocs looks nice, but I've never heard of it before.
If I had two browser tabs open to evaluate different 3rd party APIs to consume, I'd somewhat strongly lean towards the one that used OpenAPI, because I know it'd fit in with our existing toolset and experience.
The most important aspects of good API documentation are
1) correctness,
2) thoughtful and complete examples, and
3) a clear explanation of the data model and state transitions.
These can be accomplished with any tool.