I ran into some deficiencies, though, at least with the parser I was using with Node/TS -- IIRC (and it's been a few years), I wasn't able to specify a wide variety of disparate responses (e.g., an HTTP 200 with an application/json Content-Type header, an HTTP 200 with a text/plain Content-Type header, and an HTTP 400 response with an X-Error-Code header). Since API Blueprint was introduced, the tooling around OpenAPI has improved dramatically and it's become a de facto standard, so I'd probably avoid API Blueprint for anything serious.
It's unfortunate, though, because I really liked the idea.
Former company enforced OpenAPI specs to be able to publish any API endpoint, devs just wanted to push code, so they made vague shit specs because it's pulling teeth to do it the right way (didn't help that the spec enforcer couldn't fully read YAML documents with references, so copypasta was rampant)...
I guess there's the endless cycle of 1) a format is created, 2) the format evolves to do more, 3) winds up being overbearing, 4) a new format is created...
It's actively developed and used to spec Azure services, see https://azure.github.io/typespec-azure/ and all of the public Azure service specifications at https://github.com/Azure/azure-rest-api-specs (they're all OpenAPI for consistency, but newer development happens in TypeSpec, and the OpenAPI is an output).
