If I wasn't going to get the benefit of my data automatically being distributed across servers, why would I use this? In many cases, NoSQL solutions seem to be a compromise that you make, giving up ACID (yes I know this has it) and other nice query features of databases and in return gaining the ability to scale to much larger amounts of data and having redundancy without needing to think about it.
In this case though, it's all embedded so I don't gain any of the benefits.
The point being that if you need a local data store, sometimes you would rather have a document-based one where you don't have to create the code to serialize your objects into (e.g.) a SQLite database, and to reconstitute them back.
A good example would be something like an address book data store. Especially if you want it to be dynamic so that the user can add/remove fields (e.g. allowing the user to attach as many phone numbers as they like to the contact, rather than just a static 5 numbers). If you have to implement this in SQLite, then you have to develop the schema for it, and the (de)serialization code. With a document-store, you can just do something like say "store these fields" and you're done with it.
| giving up ACID (yes I know this has it)
If you know that this has ACID, then why are you talking about giving up ACID? The fact that many NoSQL implementations give up ACID doesn't have any bearing on this discussion.
In this case though, it's all embedded so I don't gain any of the benefits.