The main reason is that the backing file is random access, and transactional correctness is ensured using various locking mechanisms. Sqlite generally relies on fsync() ensuring that data is flushed to disk at certain points, so conceptually, data is written to an unused portion of the file, then fsync() is done, then various structures are updated so that this data is now live, leaving some unused space in the middle of the file, and this is fysnc()'d again. Later that unused space might be reclaimed, but only when all current readers and writers have finished.

If you cp the file, you might end up with different chunks from different points in the transaction history that don't make sense combined together. If you use ".backup", it guarantees that the data in the copy will be consistent with the data as it existed at one of the fsync() calls.

Turning off the journalling will likely increase the chance that your copy will be inconsistent, as there will be more churn in the main data file.