One major drawback is the lack of Java native tooling vs e.g. Swagger/OpenAPI springdoc project. Document generation + API validation can be part of the same build, instead of having to have a separate Node toolchain and build.

give it a time, it is much younger but since last year it got lots of attention

OpenAPI can be used to describe the vast majority of extant APIs in the wild today. It was build to describe APIs. AsyncAPI, like GraphQL, imagines a new ecosystem. This article constructs straw man arguments against OpenAPI without making a particularly concrete case for AsyncAPI.

The vast majority of extant public APIs in the wild today. Internally, people write a lot of services that process records from Kafka topics, SQS queues, emails, file uploads, etc. The ecosystem already exists and is in need of tooling.

> This article constructs straw man arguments against OpenAPI

I don't see that at all, and why would they? AsyncAPI is leveraging OpenAPI's status as a de facto standard tool for synchronous REST APIs to promote itself as a complementary standard tool for async APIs. It wouldn't benefit them to denigrate OpenAPI.

Noone is against OpenAPI, definitely on the author, thing is that OpenAPI is just not for everything and AsyncAPI complements the rest. AsyncAPI doesn't have to imagine anything, ecosystem is already there :) MQTT,Kafka, Websocket and others were there long time before AsyncAPI. I recommend you look at the article once again.