One way I’d look at this is that with JSON, that should mostly likely be data that you will always want back in one chunk, and never want to query against (ie, either filtering the contents or using the contents as the comparator within a filter). Also if the data tends to have complex relationships (ie, not purely hierarchical, but multiple objects referencing other objects in a star/net-like pattern as opposed to a tree-like pattern) JSON would not be a good option.
The other use case might be for truly unstructured data, ie when you have hierarchical data from the user but no way to predict how that data is structured. Even in this case, you should still be careful. For example, right now I have an application that allows users to define custom descriptors for various models, but what I’ve done is created a “fields” type (describing this “pseudo-property”) and a “data” type (defining entries for that particular field. This way I can query against that data more easily.
It really boils down to what kind of data you’re trying to represent, and how you’ll be interacting with said data.