Let's start with the fact that most of the data centric apis have a 80/20 split on read write, so there is virtually not SP in 80% of your api, so no need to debug 80% of the code :)

so you "might" need stored procedures only for your write part and even then you need them when the input data needs to be split and sent to different tables.

The complex "rules" are nothing more then "constraints" on your data which are split between the columns of the table and become so simple that there is almost nothing to debug.

If it were the case that with postgrest one needs to write complicated stored procedures all over the place you'd be 100% correct. The thing is you don't need them in most cases and when you do they are short simple functions that deal with focused things so there is way less chance to get them wrong.

This has been my experience with using this type of stack for apps like project management/invoicing.... etc (basically basecamp+freshbooks)