Anche la stessa libreria VCL è prevalentemente NON thread-safe, ma questo non significa che NON sia "valida".
Non uso componenti vcl ma fpc su Linux.

è necessario che ogni thread abbia una propria connessione al database
Certamente.

Questo tipo di controllo lo si effettua proteggendo la risorsa attraverso i meccanismi di sincronizzazione multithreading, cioè critical section, mutex, semafori, ecc.
La transazione mi permette di effettuare un lock sulla tabella impedendo a chiunque di modificarla fintantoché non la libero.
Nel sito si legge che sqlite è thread-safe. A tal proposito ho fatto alune prove testando l'accesso di più threads in lettura e scrittura. Non ho avuto problemi di acun genere. Ogni thread, attendendo che la tabella si liberi, ha poi concluso il suo lavoro correttamente. Da dire che le prove le ho fatte usando 16 threads contemporaneamente mentre normalmente il programma ne usa solo 3.
Inserire però delle critical section a questo punto, tanto per togliersi ogni dubbio potrebbe essere una buona cosa. Il mio sospetto è che in verità rimanga qualcosa nella cache del disco gestita dal kernel anche se la transazione è terminata ed il commit è stato dato. Leggo che firebird ha un apposito parametro configurabile per regolare questa cosa.

C'è da dire che il sistema operativo ed il database sono un supporto solido (disk on module) e non su un disco normale. Forse la cosa complica le condizioni di lavoro. Il sistema operativo ed il programma però non si fermano mai e non mi si è mai corrotto il filesystem.
L'archivio sqlite va aumentando anche se i record vengono cancellati per cui non credo che il file venga scritto sempre sui soliti punti del disco degradandolo.