At the moment, I find myself (unfortunately) somewhat ignorant of JSON-LD.
I've heard/seen some mentions that JSON-LD is not itself RDF but can be "mapped" to RDF. I'm not sure what this actually means in that if JSON-LD can be parsed/mapped into RDF triples and can encode all valid RDF graphs, then it is, to me, an RDF syntax. To me it seems purely a marketing distinction, but I'm not confident in this view.
My question then: is JSON-LD RDF? If so, why? If not, why not?
Judging from the section in the spec to which you link, all RDF models can be written down in JSON-LD, but there are JSON-LD documents conceivable that do not correspond to a valid RDF model. As far as I can tell, however, the only really fundamental difference is that JSON-LD allows blank nodes for properties.
All other differences (list support, native datatypes, blank nodes for named graphs) can be easily dealt with by any JSON-LD parser that processes to RDF. The point about JSON-LD allowing blank nodes as graph names is moot, IMHO, as first of all, named graphs are not (yet) a standard feature of RDF anyway, and second, quite a few RDF implementations already support blank nodes as graph names.
I think it's entirely a marketing distinction. For example, Google recently adopted JSON-LD as their Gmail markup syntax for annotating emails using Schema.org's properties and classes. JSON-LD.org showcases the power of Linked Data without the use of words such as RDF or URIs or Triples or Subjects/predicates/objects, allowing the Google team to understand the power of Linked Data without having to go through the somewhat steep learning curve that the Semantic Web usually has.
The JSON-LD team has done a wonderful job at this. They showcase a simple use-case scenario: the idea of uniquely identifying your JSON objects across the internet, and to be able to use the properties from Schema.org within your JSON.
Google was interested only in these features. Not in the RDF. Not in reasoning. Not in triples. Not in the Semantic Web.
But it's awesome for us that it's still entirely RDF compliant.
If one follows the standards as @JeenBroekstra mentions, it’s possible to have RDF representations and JSON-LD representations for the same graph that have 1:1 compatibility. Then, if you’re working in say Python, it only takes about 2 lines of code to convert between JSON-LD and the various ways to serialize RDF (XML, N3, Turtle, etc.) and vice-versa.
I find that in practice, Turtle format (also called TTL) is more compact and simpler for people to read and hopefully understand. In contrast, JSON-LD tends to be more effective in a few ways for machines to read and write. For example, machines reading web pages is where Google pushes Schema.org in JSON-LD (I have friends on that project, I get what they’re doing, though I do not necessarily agree 100% for my typical range of use cases).
Not that it’s an either-or distinction. For example, I believe that Parquet is much more useful as a KG serialization format.
Also, JSON-LD is really good for representing the context of some data, as well as linking directly to the relevant metadata for each data element. We have a notion of IRI which is explicit for each data element in JSON-LD. In RDF triples, the IRI info can be a bit more implicit, i.e., you may need to chase down some metadata across the vocabularies to get the proper parts needed.
The latter case of implicit metadata can make RDF more “readable” by humans, while JSON-LD can be tedious for people to read (try leading a KG team, you’ll hear people complain about that!) but that’s great for machines to “read” more consistently. It generally leads to less code needed.