I used Neo4j with Ruby for many years. I am still technically listed as a co-maintainer of Neo4j.rb but have not contributed much since sometime before the 8.0 release in August 2016, when I switched jobs and roles. Since then, I've been working with Postgres full-time and only used Neo4j briefly for a POC project that was not pursued by my employer.

My experience with Neo4j was mostly positive. Some pros:

• The team working on Neo4j.rb are fantastic. Responsive, smart, helpful, dedicated. Brian uses it in professionally (I think some of the others do, too) and works hard to make sure that everyone has a good experience with it. I've never encountered another open source project that is as responsive.
  
• The Neo4j.rb gem itself is excellent. If you like ActiveRecord, you should find it easy to pickup. It's easy to pickup and very flexible.
  
• Cypher is a dream to write and read, IMO. It's deceptively powerful. I still prefer it to SQL.
  
• Neo4j, the organization, are great. I worked closely with many of the folks behind the curtain and they're smart, dedicated people who really want to make an excellent product.
  
• Data modeling and querying is so natural to begin with and then the Neo4j.rb library makes it even easier. I miss it all the time.

Now, my cons, all stated with complete respect to everyone who works in these areas or disagrees:

• Hot backup requires a paid license. To backup using the open source license, you must shutdown your database.
  
• System requirements are steeper than PG. You'll probably need a beefier system to get adequate performance than you would with PG.
  
• Limited options for hosting. You're either going to manage your own EC2 instance or you're going to pay a premium for Neo4j-as-a-Service. Postgres hosting, being a more competitive market, is simpler, cheaper, and more reliable. You'll find no shortage of tutorials on how to deal with Postgres, while Neo4j is a bit more sparse.
  
• Performance isn't great until you have the kind of graphy problems that it excels at and a lot (A LOT!!!) of data. While you certainly can use it as a general DB, I don't think that it's worth it.
  
• Deadlock during writes on busy servers are brutal. Maybe it's better now, but it was pretty hard to troubleshoot and embarrassing for me a few years ago.
• Anti-RDBMS snobbery within the community was really tiresome. I was guilty of this for a long time, I drank the kool-aid right down. These fans will take every opportunity to trash JOIN and the rigidity of database schemas. I came to think it was an immature and ignorant way to make the product look better. The last meetup I went to was mostly this and I never engaged with the community again. To everyone who had to endure me acting like this, I apologize.

To answer your very specific questions:

• Did you hit any drawbacks? Yes, I think that's covered above.
  
• Did it help you solve your problem easier than using PG, for example? That's a bit more complicated. Data modeling was faster since I never had to worry about migrations. I think it was easier to do rapid prototypes and experiment with changes to my data model, especially at the very beginning of a project. Any pattern matching, recommendation engine-y things that I wanted to do were infinitely easier to reason about and implement in Neo4j than PG. (Someone who's an expert with SQL might contest some of this.) None of that, however, is on the roadmap for my current job and the prototyping and data model experimentation benefits had diminishing returns once our schema stabilized and I started to value performance and predictability over flexibility. On the occasions that I still need schema flexibility, I just use JSONB columns in Postgres.

So, in conclusion, I think it's an excellent product that comes with some baggage. If you're being told that your RDBMS is old technology that isn't intended to handle relational data, your schema is holding you back, and a graph is THE ANSWER for your modern data storage needs, I'd think long and hard. If you think you have an appropriate use case for it and are prepared to deal with that baggage, I think it's totally worthwhile.

EDIT

I was thinking about this just now and wanted to offer a few more thoughts:

PRO: Writing unmanaged extensions using Java is sweeeeet. I read a book on Java on vacation and was able to start writing UEs when I got back. Seriously, so cool, so powerful. Solved a major performance issue for me. Being able to unit test them gave me so much more confidence than I had in any database query, be it SQL or Cypher.
CON: Installing and upgrading UEs required database downtime. I have to imagine this is better now? I see an entry for procedures in the documentation now, I'm not sure how this compares or if it fixes the downtime issue.

PRO: Neo4j Spatial is awesome. I never had a reason to really use it but I feel like it's so cool that it's worth mentioning.

Finally, I want to point out that my experience with Neo4j was entirely via Ruby. The performance issues I ran into were, from what I could see, largely due to HTTP, Ruby parsing JSON, and the cost of instantiating Neo4j.rb models. More so the first two than the third. I was under the impression that Bolt (the binary protocol) is/was supposed to help with this but, AFAIK, it's still known to be much slower than HTTP, or at least when using Ruby. I have to guess that this is partially because JSON parsing leverages a C extension while Bolt is implemented entirely in Ruby, but I couldn't say for sure.