RLS prevents people from accessing or making changes to rows that they're not authorised to access (depending on whether it's a select, insert, update, or delete operation). In the users example, this would prevent users from changing or deleting rows for other users (i.e. other user profiles). It enforces the limit at DB level.
Protecting them at any other level has some advantages, but it wouldn't stop someone who's determined, as even without having direct access to the DB, they could look at the calls that are made from your front-end and possibly infer enough information to be able to change other user profiles. Since you're also dealing with Stripe, disabling RLS should definitely be avoided.
See, even though I'm not interested in breaking other peoples services, if I wanted to, the first thing I'd do would look at the network calls that the front-end makes and see if there's anything I could potentially exploit by changing parameters.
If you want public user profiles, you can use a view (
https://www.postgresql.org/docs/9.2/sql-createview.html,
https://www.postgresqltutorial.com/postgresql-views/) - this will allow you to show only certain fields publicly while still allowing you to enforce RLS on the table.