I’m not sure I would agree with the sentiment that a lot of people don’t like SPARQL. SPARQL 1.0 did have some short comings, but it quite nicely addressed what it was designed for, and the new iteration, SPARQL 1.1, builds upon it adding many constructs from SQL that people expected to see in the original spec including sub-queries, aggregates & update semantics. I think the fact that it’s standard and you can expect to see the same parsing & semantics in every triple store, as opposed to dialects of SQL, is a nice feature.
I would also claim that all triple stores are graph databases; you can put properties on specific edges in RDF, albeit not as nicely as you can w/ Neo4j. But triple stores have the advantage of a real query language, a w3c standard data representation which makes it trivial to take your data to another triplestore, and for a number of triple stores, the ability to perform reasoning based on OWL.
I dont know anything about the scalability for most graph db’s, but generally, the commercial RDF databases scale quite well. All can scale into the billions of triples, which handles a great many use cases. Though how they handle scale differs wildly from vendor to vendor wrt to scale up or scale out, clustering, etc. You’ll also see pretty different mem & hardware requirements to match the implementations for each. For me, I’ve tended to just go and grab an EC2 instance, usually a 2XL or 4XL, mount an EBS large enough to hold the data, and I’m pretty well set.
Additionally, some triple stores integrate with Lucene or similar technologies to provide inverted indexes over the data, and many now are starting to include geo-spatial and temporal indexes. These are very useful features that I’m not sure of their availability in something like Neo4j.
With that said, they’re not going to scale as well as a relational databases, they’re just not as mature. But you’re also not going to get screwed when you have “real” amounts of data either. Of course, one of the advantages of triples stores is reasoning, which performing at scale is tricky, but that’s much of the reason why the various OWL profiles were created. But you can paint yourself into a corner if you don’t think ahead.
I think graph databases, triple stores specifically, can be a pretty good match for a lot of applications that are being built, but I dont think that means that everything should be done with them. Like anything else, they’re tools w/ their good points and their bad points, so you kind of have to make the right choice based on your application. But they probably always merit at least a consideration these days.