Odpověď na názor

Ano, oni přesně zmiňují největší benefit u vícevláknových aplikací, kde třeba vlákna něco nezávisle počítají, výstup je do db, a přestože SQLite sama může být velice rychlá na inserty, tak zamykání logicky sundá výkon a propustnost celé aplikace (a případné další bufferování ten problém jen posune a zvýší nároky celé aplikace).
Přidali tedy celé MVCC, které umožní přístup pro zápis z více vláken a optimistické zamykání. Tzn. jako u "plnotučných" databází, s tím, že případné kolize se řeší v commit fázi na konci transakce.
V poslední verzi (vyšla před pár dny) povolili zapínání MVCC režimu přes pragmu, byť samozřejmě pak ten soubor přestane být kompatibilní s SQLite.
Ale uvidíme, u každého MVCC je pak naprosto kritická implementace čištění starých verzí (ať už se tomu říká vacuum, sweep, compacting..). Ať už kvůli tomu, kdy se to provádí, jak rychlé to je, tak i tomu v jakém stavu pak zůstane soubor na disku.
Byť u těch embedded aplikací je to z provozního hlediska trochu lepší v tom, že má autor aplikace plně pod kontrolou patterny a časy zápisu a může to čistění přímo spouštět v nějaké vhodné chvíli atp.
Jinak ty další asynchronní I/O operace, co jsem zmiňoval vychází i z toho, že to na Linuxu může používat io_uring.