EDN is natively extensible to more types, for example, the dozens of types postgres supports[1] which actually makes EDN significantly more suitable for this use case. JSON can't encode the difference between a string, a date, a timestamp, and a uuid -- they're all encoded as strings and consuming code needs to go out of band to understand the type.
the stuff about EDN being natively supported by clojure is a red herring and irrelevant.
In the general case, it has the low startup cost of a document db combined with a clear path to scalability with a future relational model.
In the specific case, it removes the data transformation code required to convert the clojure data structures I have to sql, json, or xml that postgresql understands.
So the same argument as (say) YAML, Lua tables or TNetStrings. Or, if you include binary representations, stuff like Thrift, XDR and ASN.1.
You can embed a JVM in PostgreSQL and write the functions yourself (or use PL/Scheme I suppose), but I would be basically amazed if anyone decides to do it for you.
JSON gets the nod because it's understood by billions of systems. Other formats are going to struggle.
It just seems like a particularly parochial wish, is all. And in life we rarely get what we want because potential ends are limitless and means limited.
It is not a small wish to ask them to take on supporting a serialisation format. They will need to integrate it into the core code and it will need to be supported indefinitely.
I asked because I wanted to know if there was a particular reason for your wishes -- which is, as I said, quite parochial compared to the reach of JSON -- over other potential priorities. If asking questions is "trolling", I'll be over here with 4chan and Socrates.
[0] https://github.com/edn-format/edn