Ich weiß schon, was Fremdschlüssel sind, keine Sorge. ;-)
Du kannst auch mit SQLite zwei Tabellen so benutzen, dass Spalte user_id in Tabelle kommentar auf die Spalte id in der Tabelle verweist, ohne dass das DBMS zwingend prüft, ob auch jede user_id auch einer existierenden id in der user-Tabelle entspricht. Dann musst Du halt in Deiner Anwendung Sorge dafür tragen, dass Du nur gültige Werte in die user_id einträgst.

Der Unterschied in der Frage zwischen SQLite und z.B. PostgreSQL, ist dass PostgreSQL wie gesagt prüft, ob jede user_id einer existenten id in der user-Tabelle entspricht und ein INSERT/UPDATE auf kommentar nicht zulässt, wenn das nicht der Fall ist. Und in den meisten Fällen, in denen ich SQLite einsetze, kann ich diese Prüfung mit vertretbarem Aufwand auch in meiner Anwendung ausführen.
Als anderes Beispiel sei auf MyISAM-Tabellen in MySQL verwiesen, die auch keine Foreign Keys unterstützen, aber für einfache Web-Anwendungen sehr populär waren (ist schon länger her, dass ich mit MySQL was gemacht habe, also wahrscheinlich nicht mehr aktuell).

Versteh mich bitte nicht falsch - die Fälle, in denen ich SQLite einsetze, sind sehr simpel, die Datenbank hat dann höchstens zwei oder drei Tabellen, und sobald es etwas komplexer wird, oder aber mehrere Anwendungen auf einen gemeinsamen Datenbestand zugreifen müssen, ist für mich PostgreSQL das DBMS der Wahl. Auch wenn z.B. mehrere Instanzen einer Anwendung parallel auf eine Datenbank zugreifen, ist PostgreSQL von der Performance her einfach besser.
Und wenn ich z.B. eine Auftragsverwaltung schreiben müsste, bei der es inakzeptabel wäre, dass da auf einmal Aufträge ohne dazugehörigen Kunden herum liegen, dann würde ich mit Sicherheit kein SQLite einsetzen.

Dass SQLite sich eher als Nischenlösung versteht, wird für mich auch am Typensystem deutlich, das a) nur vier Typen kennt (Integer, Real, Text und Blob) und b) in den meisten Fällen erlaubt, beliebige Typen in beliebige Spalten einer Tabelle zu speichern. Was für viele einfache Anwendungsfälle völlig in Ordnung ist - wiederum: wenn nur eine einzelne Anwendung auf die Datenbank zugreift, kann ich in der Anwendung sicherstellen, dass ich keinen Unsinn in die Datenbank schreibe. Sobald es mehrere Anwendungen werden, oder ich absolut sicher gehen will, dass in einer Spalte nur gültige IPv6-Adressen oder eMail-Adressen stehen, ist dann wieder ein ausgewachsenes RDBMS fällig.

In den Fällen, in denen ich SQLite einsetze, würde ich sogar sagen, verwende ich das gar nicht unbedingt als Alternative zu einem ausgewachsenenen RDBMS, sondern als Alternative zu einem selbstgestrickten Dateiformat, XML (*schauder*) oder solchen Geschichten. In den Fällen würde ich vor einem Client-Server-basierten RDBMS zurück schrecken, weil dann auf einmal der Aufwand hinzu kommt, den Server zu administrieren.

[Ich erwähne des Öfteren PostgreSQL, weil das mein ausgewachsenes RDBMS der Wahl ist; wer diese Meinung nicht teil, setze da bitte Oracle/DB2/MySQL/Firebird/ ein.]

Also, um es kurz zu sagen, ich verstehe schon, worauf Du hinaus willst und wieso Dir der Gedanke an ein RDBMS, das keine Fremdschlüssel versteht, Bauchschmerzen bereitet; aber es gibt halt Szenarien, in denen das kein echtes Problem ist, und in denen hat SQLite seine berechtigte Rolle.

Cheers!