You would implement those rules in code anyway as ideally data consistency rules in the database such as foreign keys or check constraints should be a "last line of defence".
Besides architectural reasons, the practical reason behind that is that it is very hard to figure out what went wrong based on a database error you get when you violate a constraint. It is a lot easier to detect things like that in code and not allow them to propagate into the database in the first place.
Note that I'm definitely not saying that database constraints are not important, I think they are very important and I use them whenever I can, all I'm saying is database constraints in themselves are not really enough.
Nobody needs FK: Anything you can implement with FK, you can implement with tedium, code duplication and transactions.
Having FK in SQLite means less tedium, less code duplication, and/or fewer transactions.
I can't imagine why anyone would be upset about this: It's easy to remove with a single `-DSQLITE_OMIT_FOREIGN_KEY` if you need the smaller code size.