The naive bit comes from the fact that data is persisted as plists in files to make them human and machine readable, also there is no rocket science code.
The store was designed to be customisable, just about anything can be customised, have a look at the implementation api to get an idea of what is possible.
Data can be written to file per document update or as a batch update.
Data is loaded into memory for querying and lookups, that makes them fast.
Data is only loaded when needed and not before. If you use the store correctly it means that you will only have the data that users requested up to that point in memory.
Documents and key values can be indexed, and a user can specify their own additional indexes as well. Queries and lookups can both be done using indexes which speeds up the retrieval of data considerably.
Sharding is the breaking down of files into smaller files, in the case of naive-store that means that instead of one file per collection there could be many.
Sharding is done based on the actual data in collections. The user specifies which elements of a document it wants to use for sharding on a collection. If none is specified no sharding is done.