A couple of things come to mind about your experiment.
We've never compared the bulk insert path into the Oracle RDBMS to NoSQL inserts because we don't have a true bulk insert mechanism yet. We've focused initially on general purpose, finer granularity operations. Using the execute function to group a number of NoSQL DB operations optimizes the network communications cost, but on the NoSQL DB server side, the operations are done individually. A more apples to apples approach would be to compare the cost of non-bulk insert operations, but if your application finds the bulk insert model suitable, then it makes sense to do the comparison that you are doing. We would like to have a bulk insert in the future.
Our focus has been on providing horizontal scalability, so our performance efforts are generally based on benchmarks with larger data sets. We do find that smaller benchmarks need evaluation to determine whether one is seeing true server side performance, or whether a client side test issue is dominant. The Admin Guide and FAQ mention the server side <storename>.perf files, which show per-node performance metrics, and that can be a useful first step to get a sense for performance. For example, we have found that an insufficient number of clients can be a gating factor when driving a large benchmark.
Do keep in mind that the single KVLite instance is not meant to be a performance tool. In particular, the cache size is small for that instance. The capacity sizing guide at the end of the Admin Guide provides a comprehensive look at the performance factors to consider, but in general, if I had to guess with no context, cache sizing at the replication nodes is often one of the first parameters to tune. This FAQ entry FAQ - Oracle NoSQL Database
talks about how to use the memory_mb parameter for the Storage Nodes to set cache sizes. But it's just a guess whether that is the first factor!