It's real RDF. You can process this with RDF tools. Certainly do SPARQL queries. Probably add a schema and have valid OWL DL and do OWL inference if the data is squeaky clean. Certainly use SPIN or Jena rules.
It leans too hard on text and doesn't have enough concepts defined as resources but what do you expect, Python didn't have a good package manager for decades because 2 + 2 = 3.9 with good vibes beats 2 + 2 = 4 with honest work and rigor for too many people.
The big trouble I have with RDF tooling is inadequate handling of ordered lists. Funny enough 90% of the time or so when you have a list you don't care about the order of the items and frequently people use a list for things that should have set semantics. On the other hand, you have to get the names of the authors of a paper in the right order or they'll get mad. There's a reasonable way to turn native JSON lists into RDF lists
although unfortunately this uses the slow LISP lists with O(N) item access and not the fast RDF Collections that have O(1) access. (What do you expect from M.I.T.?)
The trouble is that SPARQL doesn't support the list operations that are widespread in document-based query languages like
but the community badly needs a SPARQL 2 that catches up to today's query languages but the semantic web community has been so burned by pathological standards processes that anyone who can think rigorously or code their way out of a paper bag won't go near it.
A substantial advantage of RDF is that properties live in namespaces so if you want to add a new property you can do it and never stomp on anybody else's property. Tools that don't know about those properties can just ignore them, but SPARQL, RDFS and all that ought to "just work" though OWL takes some luck. That's got a downside too which is that adding namespaces to a system seems to reduce adoption by 80% in many cases because too many people think it's useless and too hard to understand.
My point is that even if technically its rdf, if all anyone does is use a few specific properties from a closed pre-agreed schema, we might as well just be using meta tags.
But there's the question of who is responsible for it and who sets the standards. These days the consortium behind HTML 5 is fairly quick and responsive compared to the W3C's HTML activity in the day (e.g. fight with a standards process for a few months as opposed to "talk to the hand") but schema.org can evolve without any of that.
If there's anything that sucks today it is that people feel they have to add all kinds of markup for different vendors (such as Facebook's Open Graph) I remember the Semweb folks who didn't think it was a problem that my pages had about 20k of visible markup and 150k of repeated semantic markup. It's like the folks who don't mind that an article with 5k worth of text has 50M worth of Javascript, ads, trackers and other junk.
On the other hand I have no trouble turning
<meta name="description" content="A brief description of your webpage content.">
into
@prefix meta: <http://example.com/my/name/space> .
<http://example.com/some/web/page> meta:description "A brief description of your webpage content." .
where meta: is some namespace I made up if I want to access it with RDF tools without making you do anything
In which case we have all been on it since the mid 90s.