I see JSON-LD show up in a lot of standards-driven document formats and it's made sense to me in that context. For instance, in DIDs^1 the basic document shape is established by one standard but then the key material is often identified using other standards. JSON-LD makes possible to merge together the definitions from the multiple standards without too much trouble or loss of specificity.
How you actually use JSON-LD seems to vary in practice. Programmatically, the most useful thing it can do is normalize a JSON into a shape you expect without losing specificity^2. More often, however, it serves as a form of documentation for where the terms are coming from, because developers will usually try to maintain a nice shape with the JSON documents they produce.^3
The @context is hard for developers to create, however, so outside of the standards process I'm unsure it gets a lot of utility. I'm also unsure how reliably the @context values have consistent machine-readable documents produced, so the programmatic value may be limited.
^1 Which we'll assume are a good thing for the purpose of this conversation.
^2 You can do this by expanding the JSON into the very noisy RDF graph-triple form, then re-condensing it into an object with sane (unprefixed, non-URL) keynames and values using your own @context.
^3 Of course you can't RELY on people to do that, which is where the programmatic utility comes into play.
I find that a bit implausible since the semantic web is designed as an interop layer, not implementation-level tech. The whole point of it is lost if you keep it a secret!
The real ideology behind the semantic web is that you can use something like RDFS to rewrite the vocabulary somebody else uses to what you want... Except there are a number of reasons why you can't, for instance it is reasonable to write
:Today :temperatureInCentigrade 28.8 .
but maybe you want to query
:Today :temperatureInFahrenheit 84.0 .
The production rule to convert one to another is pretty simple, and you can implement it with SPIN, but not RDFS or OWL. Similarly there are data formats that organize a tree-like structure in an arbitrary way and to convert one to another you have to match a graph pattern to a graph pattern not a predicate to a predicate.
The whole fun of RDF is it is a clean basis to build your own data model. Want to add some kind of reification? Just add properties to triples.
I look at the OMG standards for an example where broken standards are par for the course because a few organizations fix the standards and can build proprietary tools on them. For instance the claimed reason why EMOF exists is that you could bootstrap UML 2 from it. It's not quite possible because the standard is broken. I'm pretty sure you can fix a few small things with EMOF and get it to work but it's not accidental it all it doesn't work out of the box.
The semweb community is absolutely sick of the standards process which is one more reason why broken things don't get fixed.
How you actually use JSON-LD seems to vary in practice. Programmatically, the most useful thing it can do is normalize a JSON into a shape you expect without losing specificity^2. More often, however, it serves as a form of documentation for where the terms are coming from, because developers will usually try to maintain a nice shape with the JSON documents they produce.^3
The @context is hard for developers to create, however, so outside of the standards process I'm unsure it gets a lot of utility. I'm also unsure how reliably the @context values have consistent machine-readable documents produced, so the programmatic value may be limited.
^1 Which we'll assume are a good thing for the purpose of this conversation.
^2 You can do this by expanding the JSON into the very noisy RDF graph-triple form, then re-condensing it into an object with sane (unprefixed, non-URL) keynames and values using your own @context.
^3 Of course you can't RELY on people to do that, which is where the programmatic utility comes into play.