Absolutely. If they just dirty some pages in memory and return back to the client the benchmarks will look "insanely fast".

I have nothing against this being a non-default option in a db/kv engine but anything advertising to be durable and not fsyncing by default is something I would stay away from. To me it's like a litmus test of how well the author knows/cares data durability and not destroying users data.

durable() syncs periodically on flush, WAL rotation, and clean close; paranoid() is the sync-before-ack mode. This is clarified in the README, and the benchmarks report all three modes separately. Other KV-stores that you see on the market, do this too. It's a performance tradeoff most applications make. Sync on every write kills every optimization. See the benchmark table for example.