Disclaimer: I work for/with Neo4j
Just talking about the maturity here (not technicalities) - Neo Technology as a company with more than 50 employees, $25M funding and a thriving user-base with half a million downloads, 30k new databases running each month and an active community won't go away. You can also check the SO questions to see the community activity.
We have a healthy set of customers in many domains from big ones like Adobe (runs creative cloud on Neo4j), Cisco (Org-Management, MDM), social networks like Viadeo and many Job search companies (GlassDoor, and others) to startups like fiftythree who published the popular "Paper" app on iOS.
Our community site neo4j.org should be a good place to go, to get started, you find there introductory content as well as information on programming languages, drivers and deployments that should help you get started.
Emil, Ian and Jim wrote an introductory book about "graph databases" with O'Reilly which is currently available as a free ebook download.
So you see we're not just taking care about our own product but also the bigger graph ecosystem, also with many conference talks, meetup groups (41 worldwide) and support of the open source ecosystem.
Hope that helps you deciding.
P.S. Regarding your concerns:
The size limits (which are artificially anyway) will be increased this year.
The deeper the object graph, the more the performance advantage swings to object/graph databases.
Relational database performance drops off markedly with more than seven JOINs.
Geometric systems such as CAD/CAM, with deep object graphs for bills of materials, outperform their relational counterparts.
Relational databases have one huge advantage: relational algebra and a clear separation between the data and the "how" of accessing and manipulating it. But they are not perfect for every problem.
Best Solution
Many relational representations of graphs aren't particularly efficient for all operations you might want to perform.
For example, if one wants the connected set of all nodes where edges satisfy a given predicate, starting from a given node, there's no natural way in SQL to express that. Likely you'll either do a query for edges with the predicate, and then have to exclude disconnected edges locally, or have a very verbose conversation with the database server following one set of links to the next in iterated queries.
Graphs aren't a general replacement for relational databases. RDBs deal primarily in sets (tables), while graphs are primarily interesting because of the "shape" of interconnections. With relational DBs you follow links of a predetermined depth (a fixed number of joins) between sets, with results progressively filtered and grouped, while graphs are usually navigated to arbitrary and recursively-defined depth (i.e. not a predetermined number of "joins"). You can abuse either to match the characteristics of the other, but they'll have different strengths.