So, two protocols? Two standard protocols is rarely better than one.
> having such a standard protocol makes sense in the age of web apps
Only if the existing standard protocol cannot work with the "web", and we have plenty of history proving otherwise. Replacing the existing standard with the loose JSON would be, strictly, a downgrade; and unnecessary, because we already do interoperate JSON and SQL. See: PostgREST and the many REST & GraphQL frontends on PostgreSQL.
> particularly when NoSQL offerings that are perceived by the market as competitors (leaving aside whether they really are - perception matters more here) do that already
This is really more of going into a pig's pen and wrestling with them. A database should do the job of a database. Competing for perception in a market that cannot make sane decisions for itself is how we get MongoDB.
Have you seen the PostgreSQL wire protocol[1]? I recently built a logical replication client driver for a project and found the protocol to be excellent. After looking at the documentation, I'm no longer limited to languages that have drivers for Pg, because I know how easy it'd be for me to just write one.
Just because some SQL drivers and wire protocols are awful (looking at you, Oracle[2]) shouldn't mean one should go running to the hills, let alone to JSON.
----
1: https://www.postgresql.org/docs/current/protocol.html
2: https://noss.github.io/2009/04/28/reverse-engineering-oracle...