Row level security is the security boundary

If your database rows are protected by a check in your application code, they are not protected. Anything holding a key can talk to the database directly, and your code is not in that path. Row level security moves the rule into the database. A policy says which rows a given user can see or change, and it applies to every query from every client, including the ones you did not write. The practical shape of it: Public content is readable by everyone and writable only by staff. Personal data such as bookmarks, history and saved progress is readable and writable only by the row owner. Counters and aggregates are written by a security definer function, because the table itself is not user-writable. Application checks are still worth having as defence in depth. They are just not the thing standing between a stranger and your data.