That's what Ron Ratovsky said some time ago. He's allowed to change his mind. :)
Ron is also one of the maintainers, but then so am I...
Personally, I've recently made a study to compare different options to define the structure of the data exchanged between the systems using JSON encoding. The final choice I had to make was not OpenAPI because:
I really want to be able to talk just about the data. It might be RPC. It might be messaging. But the data will be (mostly) the same. Of course, you also want to define transport thingies like paths and response codes as well once you get to it. But the data and its structure exchanged by the systems are largely independent of particular transport.
I fear that once unapproved workaround like empty paths is added, the tooling support could degrade rapidly. Again, talking about the data, I would like to be able to validate JSON file for compliance with defined structure. I want to be able to do this in runtime, during build time and when editing the schema or file with data. Most tools for OpenAPI are around REST and it is not quite trivial to validate chunk of data.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.