Short answer... to preserve data integrity (i.e. accuracy and validity).
If the database is just storing a single-application's data for a single-user, such as in most Sqlite databases, it may not need constraints. In fact, they usually don't, so as to keep the access time so quick it's unmeasurable.
For everything else...
Databases always serve two masters which I'll call editors and users.
Editors mostly put data into the database and retrieve data one or a small number of records at a time. Their primary concerns are fast, accurate access to all the related pieces of data and fast, reliable storage of their changes.
Users mostly retrieve data and are most concerned with fast access to unquestionably accurate information. They often need various counts, aggregations and listings that used to be generated in those iconic foot-thick stacks of greenbar-paper printouts but usually wind up on web pages today.
Database development projects are almost always started at the behest of Users, but the design gets driven by the data-entry and record-at-a-time needs of Editors. As such, inexperienced developers often respond to the immediate need for speed (primarily, of development) by not putting constraints in the database.
If one and only one application is ever going to be used to make changes to the data for the entire life of the database, and that application is developed by one or a small number of well coordinated individuals, then it might be reasonable to rely on the application to insure data integrity.
However, as much as we pretend we can predict the future, we can't.
The effort to produce any database is too valuable to ever throw it away. Like a house, the database will be extended, altered, and renovated many times. Even when it is completely replaced, all the data will be migrated to the new database while preserving all of the old business rules and relationships.
Constraints implement those rules and relationships in a concise, declarative form in the database engine itself where they are easily accessed. Without them, subsequent developers would have to pour through the application programs to reverse-engineer those rules. Good Luck!
This, by-the-way, is exactly what mainframe COBOL programmers have to do as those massive databases were often created before we had relational engines and constraints. Even if migrated to a modern system like IBM's DB2, constraints sometimes aren't fully implemented since the logic of the old rules, embodied perhaps in a series of COBOL "batch" programs, may be so convoluted as to not be practical to convert. Automated tools can instead be used to convert the old COBOL into a newer version with interfaces to the new relational engine and with a little tweaking, data integrity is preserved... until a new app is written that subtly corrupts everything and the company is hauled into court for, say, foreclosing on thousands of home-owners they shouldn't have.