Except it isn't "SQL" it's first-order predicate calculus - a provably sound way to store and query your data.

But if one is going to use a key-value store anyway, where is the "mangling"? Building a key-value store in an SQL database is trivial (this below is for PostgreSQL):

    create table keyvalue (key text, value text);
    create index keyvalue_idx on keyvalue(key);

And use is trivial as well:

    insert into keyvalue (key, value) values ('key', 'value');

    select value from keyvalue where key = 'key';

[edit] formatting fix.

It is not nice to have to manipulate JSON as a plain string (you miss out on validation, have to manually construct like expressions for queries, and I don't even want to think about what you'd have to do to update part of a document), at least using "plain old SQL". (PostgreSQL's native JSON support would make it quite easy, but that supports my point)

If you need to query JSON content, why to store it like plain string, to begin with? Parse it at application level (or even in stored procedure) and store like ordinary fields. Or use hstore.

Postgres additionally has a json field type.

That is for now, until PostgreSQL 9.3 released, have only one useful feature comparing to plain string - validation. That's not much help, and that original lmm's point was about.

Redis. Riak. Rethinkdb. Cassandra (with a mapping layer). SQL (with a mapping layer). SQL, in a JSON-typed column (PostgreSQL supports it). SQL, in a blob field, plus indexes. I could go on.