Your database should be the central storage of this data and it should do it's hardest to guarantee that everything is consistent. Consistency means referential integrity over foreign keys, but it also means that values of attributes are well within their specified domain. And "D]7843bn;hdbnb" is not valid JSON, so the database should reject that.
If your database is already doing these checks, then it can simplify anything that builds on them, because you already have huge amounts of guarantees.
Other guarantees you would add are unique constraints, exclusion constraints, check constraints, and so on.
So it might only benefit 1%, but what's the problem with that? If you want to stuff JSON into a text field, no one is stopping you. Of course, now you'd have much less reason to do so, and would be loading a gun getting ready to shoot yourself in the foot...
...instead of "would be loading a gun getting ready to shoot yourself in the foot" I'd see it as building an app that could easily be maintained by a/more programmer(s) with no advanced DBA knowledge (less people with less expertise needed, and have the really smart know-it-alls work on more interesting things - and yes, I am thinking this from a MANAGER'S perspective, guilty on that ;) )
If your database is already doing these checks, then it can simplify anything that builds on them, because you already have huge amounts of guarantees.
Other guarantees you would add are unique constraints, exclusion constraints, check constraints, and so on.
So it might only benefit 1%, but what's the problem with that? If you want to stuff JSON into a text field, no one is stopping you. Of course, now you'd have much less reason to do so, and would be loading a gun getting ready to shoot yourself in the foot...