stands up I'll admit one of my sins

I have occasionally stuffed json into proprietary software data fields to get that data accessible/usable by another system.

(High performance not required)

OK… there are some exceptions where it makes sense. In the web dev world, though, the overwhelming majority of cases I’ve seen it used are along the lines of “we don’t know what we might need later,” AKA “either product didn’t adequately specify the requirements, or we didn’t do proper data modeling.”

That could be a virtue.

And some closed proprietary software does things like adds a few additional fields for pragmatic end user extensibility like this.

The practice predates JSON, but sometimes your bespoke string or ID or whatever in field "Custom 1" is all compromise you need to make things work well.

I've used JSON as an additional options input to a native-compiled CLI program's various commands because 1) the schema of each option is radically different, 2) they need to be passed most of the way down the call stack easily for each stage of our calculation and report generation.

It works fantastically well, and don't let anyone tell you that you MUST bloat the CLI interface of your program with every possible dial or lever it contains. We should all be cogent of the fact that, in this very young and rapidly evolving profession, textbook and real-world best practice often do not overlap, and are converging and diverging all the time.