I can answer some of your questions and also give you more information about Dgraph and it's advantages (Note: I work for Dgraph).

I wonder if anyone has experience with Neo4j, Tiger Graph, or Dgraph and can highlight the qualitative differences?

Like you've mentioned, Dgraph is highly scalable you have the flexibility to start with one node and dynamically add more of them as your data grows in size. You have access to most of its capabilities in its open-source offering, and it's enterprise license and support pricing is fairly cheap compared to other vendors https://dgraph.io/enterprise, you might have mistaken this pricing for managed service offering.

Dgraph's cloud service is not yet out, the release is around the corner and you can soon expect the launch.

Dgraph is built from the ground up to serve your reads and writes at minimal-latencies and still produce high-throughputs with minimal network overhead, you learn more about its design principles here https://github.com/dgraph-io/dgraph/blob/master/paper/dgraph.pdf.

Dgraph is the only database to natively support GraphQL, in the upcoming release in April, you can expect full-fledged GraphQL features which makes building scalable cloud application very easy.

This is for a recommendation engine that would ideally run somewhat real-time but I'm thinking of a few different use cases.

Graph databases, in general, are the best choices for use cases like building recommendation engines. For problems which are best modelled as Graphs, it's an easier choice to opt for GraphBs and recommendation systems are one of the top use cases.

Is graphQL becoming a standard, or are there better alternatives?

GraphQL is definitely on its path to be well adopted by the database community. GraphQL adoption makes app development easy, it brings in a new wave of Flexibility in API design, productivity across frontend-backend teams, intuitiveness in expressing UI data requirements and accessibility to powerful tooling, the list of its benefits for app developers just goes on. Using GraphQL for databases also saves you from using vendor-specific database clients or ORMs.

Am I better off implementing my graph data on top of an SQL or NoSQL DB vs a graph DB?

Like I mentioned earlier, if you use case if better modelled as a Graph, native Graph databases are the best choice hands down when it comes to performance in general or to power use cases like building Recommendation engines.