Even supposing this is an easier way to do without constraints, the effort to weaken static guarantees should be looked at askance. The great merit of Postgres' JSON types is that they <i>can</i> be used without losing strong data integrity guarantees.
Yes. In our case, though, Rockset is not a transactional database, but a query engine on top of existing data, so we're not the right place to enforce constraints anyway.
That's on my TODO list, both in terms of performance and in terms of features / ease-of-use. (Another interesting thing to compare against is SQL++ (https://ci.apache.org/projects/asterixdb/sqlpp/manual.html) which has a couple of usability affordances that we might adopt.)
I think the main difference between our flavor of SQL and CockroachDB's (or PostgreSQL's) is that we don't have a specific "json" data type, but rather:
1. We don't need you to specify the types of any fields, indeed, we don't even need to know upfront which top-level fields ("columns") may exist in the document.
2. You don't need to use special operators / functions to deal with JSON-typed values.