Yes and that's a fundamentally different problem; I think this is because there is always some kind of state in a protocol. SOAP has this problem, and also YANG[1] and tools that try to replace SNMP. You can never abstract away the state that the consumer and producer of the protocol has. There are lots of tools to disect, debug, resend and parse network protocols like IP and TCP but in those protocols we know there is a state built in that can not be broken, so we do not build OpenApi for them.

OpenApi specifications that need three or four requests to reason with are a lot harder to work with than ones that are only one request, and these are different beast they become protocols. In my personal experience the binary specification often are protocols with a lot more implicit state in them, e.g. binary diff of in memory struct etc. You quickly lose the usefullness of Swagger the more state you have.

That said there are lots of good example of binary protocols that try to be stateless.

Conclussion: This blog post need to be scoped a bit better, what kind of binary communications do you want an OpenApi for and how is that different from what exists today?

As soon as you have to encode the state of the application in the specification of the protocol (like TCP above) things get really complicated.

[1] https://en.wikipedia.org/wiki/YANG