Reference: https://www.sqlite.org/faq.html, question 19. (I've seen similar when testing on SSDs locally).
It has generally become much better in the last decade or two, but one should still expect most OS's to sometimes pause for excessive amounts of time on disk IO unless the API is specifically guaranteed to never pause. Even then one would be wise to measure/log deviations if it's critical for the application. OS guarantees might also be contingent on driver/subsystem guarantees, and bad drivers might sometimes affect what seems completely unrelated upstream systems.
Yes, and other file formats encourage doing things in memory, so you don't have any disk i/o in the common path.
Using sqlite as a file format strongly discourages the simple, jank-free until you press save workflow of slurping your content, operating on it in memory, and then outputting it all in one operation as a response to an explicit user action. Instead, your whole application gets small but perceptible delays across all operations and interactions.
It's not "their" experience report.
And to be clear: this will still be user-visible with literally any other file format. The slow part ain't SQLite itself; it's the disk to which you're writing.