Dają Ci większe bezpieczeństwo. Teoretycznie można powiedzieć, że takie same zabezpieczenia można by zrobić w back-endzie aplikacji, ale ja uważam, że nawet jeśli jest to w back-endzie to i tak warto dodać jeszcze jeden poziom zabezpieczeń na samej bazie. Jest to szczególnie ważne np. jeśli robisz jakiś system CRM i masz wiele połączonych ze sobą informacji.
Znajdą się jednak pewnie osoby twierdzące, że zabezpieczenia na bazie nie mają sensu, bo i z takimi wypowiedziami się spotykałem. Ja jednak uważam, że skoro bazy dają nam dobre narzędzia to warto z nich korzystać, podobnie jak np. z widoków które uważam za bardzo dobry twór, ale też wiele osób nie wiedzieć czemu ich nie lubi... Ja wolę np. robić proste selecty do widoków bez bawienia się w joiny niż tworzyć w API skomplikowane zapytania...
Ale to już kwestia gustu i tego w jaki sposób podchodzisz do bezpieczeństwa danych. To tak samo jak dyskusje na temat usuwania rekordów. Wg mnie szczególnie przy danych istotnych jak np. dane osobowe, nie powinno się nigdy ich usuwać, ale co najwyżej dezaktywować (np. stworzyć pole active 0/1), ewentualnie wyrzucać do oddzielnej tabeli (choć to nieco komplikuje niektóre operacje wyszukiwania). Są jednak osoby, które twierdzą, że jeśli user świadomie usuwa jakąś informację to nie ma sensu mu tego ograniczać... W praktyce jednak użytkownicy nie zawsze są świadomi tego co robią. Mój tata pracował wiele lat jako analityk baz danych (duże bazy m.in. finansowe oraz ludności) i nauczył mnie, że do użytkownika obsługującego aplikację zawsze trzeba mieć podwójnie, albo i potrójnie ograniczone zaufanie :)