Exactly because the consumers of those API's exhibit a strong preference for one or the other.
Library/module/API developers often seek to deliver maximimum adaptibility in their interfaces so that consumers of them can satisfy their own more specific/pressing requirements.
imo it's mainly because protos are unusable on the web without something like grpc-web (which requires a proxy) and in general web support in protobufs always seemed like an afterthought, just barely working (if at all) which is kind of ironic considering it came out of Google
I've never used protobufs with web, but I don't see why not. gRPC, on the other hand, requires HTTP/2 which can be a luxury. I remember making a side project that uses gRPC a while ago and trying to deploy on GCP AppEngine, only to find out it doesn't support gRPC.
We've used it. It's useful to define the contract between teams.
So you have 2 teams do a meeting, we work out a contract we like, dump that into a jsonschema and you can enforce by unit tests that schema is respected on each side (producer/consumer)
I've seen OpenAPI/Swagger in the wild a few times. It's a good way to specify the API for an HTTP server, whether it's JSON or something else. Biggest downside is the confusing name change.