Here are my gripes:
1) For me one of the biggest selling points is client code gen (https://github.com/OpenAPITools/openapi-generator). Basically it sucks, or at least it sucks in enough languages to spoil it. The value prop here is define the API once, code gen the client for Ruby, Python and Scala (or insert your languages here). Often there are a half dozen clients for each language, often they are simply broken (the generated code just straight up doesn't compile). Of the ones that do work, you get random PRs accepted that impose a completely different ideological approach to how the client works. It really seems like any PR is accepted with no overarching guidance.
2) JSONSchema is too limited. We use it for a lot of things, but it just makes some things incredibly hard. This is compounded by the seemingly limitless number of version or drafts of the spec. If your goal is interop, which it probably is if you are using JSON, you have to go our and research what the lower common denominator draft spec JSONSchema support is for the various languages you want to use and limit yourself to that (probably draft 4, or draft 7).
On the pros side:
It does make pretty docs - kinda wish it would just focus on this and in the process not be as strict, I think it would be a better project.
For internal projects we use grpc which is a breeze to use in comparison.
Quoting from https://www.finedininglovers.com/article/can-passive-pasta-r...
"The response was swift, and it came from starred chef Antonello Colonna. The Roman cook rejected Parisi's solution, claiming that with this procedure the pasta becomes "rubbery", and impossible to serve in a high-level restaurant. Colonna considers the method a failure and proposes cooking on an open-fire grill, with pots that have fed entire generations like a cauldron. The chef claims this traditional low-temperature technique lowers electricity costs in his restaurant."