Here's my take.
RDF standards, in themselves, don't address all of the issues needed in a data wiki. I've been thinking about the math for data wikis and it seems to me you could have a bipartite system where you have "the fact" and then "the operational metadata about the fact" and these are conceptually two different things. Then you can query against the operational metadata to project out RDF or similar facts.
Had the Wikidata people had the right idea at the time and had good luck, they might have been able to build such a system. As it is they came up with a plan they were able to execute and they did it well.
The real trouble with an RDF export from Wikidata is that if you do a complete export, you're going to get something tangled up that you can't query easily with SPARQL.
There are really two answers to this, one of them the essentially forward-chaining approach of "create a canonical data model" (it doesn't need to be the "one ring to rule them all" for the whole web, just the one you need for your job), then you can project out an RDF graph where you've expressed your opinions about all the opinions in Wikidata.
There's a backwards-chaining kind of strategy where you, effectively, try running the query multiple times with different strategies and then do data clean-up post query. That's an interesting topic too, one that again demands something beyond ordinary RDF. Since RDF and SPARQL are so well specified it also possible to extend them to do new things, such as "taint" facts with their original and propagate it to the output.
I think also people too are realizing ISO Common Logic is a superset of RDF and it is really about time that support for arity > 2 predicates comes around.
Note that arity>2 is already exists in W3C specifications, in that the fundamental object in SPARQL is a "SPARQL result set" which is an arbitrary-length tuple of nodes. It is clear what should happen if you write a triple pattern like
{
?s ?p ?o1 ?o2 ?o3 .
}
This also gives a more direct mapping from SQL to SPARQL, one that would be comfortable if there was some syntactic sugar to specify fields by names.
Yes, you can fake it by writing triple patterns, but in practice people struggle to even get simple SQL-like queries to work right, and can't do the very simple things people did with production rules systems back in the 1970s.
OWL was designed on the basis of math, not on the basis of "what are the requirements for large scale data integration". Thus it lacks very basic facilities, such as numeric conversions between, say, heights, in different units.