I've got a strong feeling this is an older complaint, possibly several years old and out of date. I can address some of these, some of our other users have addressed other parts as well.
bottleneck with large volume of writes due to slave/master topology
Our older HA clustering used slave/master topology. That has been deprecated for some time, and was removed with our Neo4j 4.0 major release. We've been using causal clustering for years now, which is based on the Raft protocol and doesn't fit the description they provided.
issues with bulk loading, indexing (e.g. range, sort, etc), slow upsert
Our indexing has improved over the years. We migrated away from lucene indexing (which was slow for insertion, possibly the reason for the older complaint) and went to a native indexing structure which is faster for index writes. As mentioned our indexing has improved as well, allowing composite indexes and a fulltext index for more complex substring matching.
confusing license terms for production use
We've addressed this over the past few years, it is simplified now.
heap allocation and GC cause out-of-memory errors
Heap and GCs are usually due to huge transactions. Neo4j is an ACID database, and as such, transactions must be committed atomically. This means any pending changes in a transaction must be held in memory at the same time and applied all at once, so it's possible to craft queries (by accident or design) that eat up all your heap space. You may need to break down larger transactions or batch changes if there's too much to apply in a single transaction. Managing that and understanding how this works is mostly the user's responsibility, but more capabilities have been added in our recent versions to restrict how much heap memory is allowed to be used per query, to keep things under control. We'll continue to add capabilities to manage this. Note that if you're comparing to a non-ACID database, they may not have this issue to deal with, but as a consequence you may not have atomicity in transactions, and you may have other issues due to the database being non-ACID. Choose the right tool for the job and your needs.
practically only useful for small dataset reads that require visualization
We're used by some of the top companies from around the world, so clearly that statement is not true.
If you have issues with out of memory exceptions, reach out to us. If you have an enterprise license with us, you probably have an enterprise support contract, so leverage that. If not, ask on the forums. We're happy to assist.
Neo4j is a powerful tool, but as with all powerful tools, you need to know how to use it well, and there is learning involved. We're happy to lend a hand.