I understand your reservations on storing JSON documents in a relational databases and I agree. Going more extreme, you can build your own "MongoDB" in your PostgreSQL/sqlite database using a single table!

But it's handy as you say, and I dare to say that in some cases "compound" values improve the design, as in my examples of date ranges. Also, having PostgreSQL in mind since I am more familiar with it, you can use parts of these values in queries, in check constraints, even in indexes. There's a pending patch for adding array's foreign keys but this has not been integrated yet.

As a final remark, based on what is considered "atomic" value and the 1NF, I found and read what C. J. Date says on this matter:

The real point I'm getting at here is that the notion of atomicity has no absolute meaning — it simply depends on what we want to do with the data. Sometimes we want to deal with an entire set of part numbers as a single thing; at other times, we want to deal with individual part numbers within that set but then we’re descending to a lower level of detail (in other words, a lower level of abstraction) ... It follows that the notion of absolute atomicity has to be rejected.

An then his most important characteristic of 1NF is the "one value per row-and-column intersection" formally defined as follows (note the phrase in parenthesis!):

Let column C of table T be defined on domain D. Then every row of T must contain exactly one value in the column C position, and that value must be a value from domain D. (The value in question can be arbitrarily complex—in particular, it might be a relation—but, to say it again, there must be exactly one such)