Normal views aren't designed for security. There are a number of ways that they can "leak" information that is supposed to be hidden.
The reason is that the optimizer reorders operations. So, a tricky person can write the query in a way that, for example, throws a divide-by-zero error if someone's account balance is within a certain range, even if they don't have permission to see the balance. Then they can run a few queries to determine the exact balance.
RLS builds on top of something called a "security barrier view" which prevents certain kinds of optimizations that could cause this problem.
It also offers a nicer interface that's easier to manage.
I may be wrong in the level of separation that pgsql provides in such situations, but it appears that a materialized view offers another level of isolation that would make such leaks more difficult to handle.
The reason is that the optimizer reorders operations. So, a tricky person can write the query in a way that, for example, throws a divide-by-zero error if someone's account balance is within a certain range, even if they don't have permission to see the balance. Then they can run a few queries to determine the exact balance.
RLS builds on top of something called a "security barrier view" which prevents certain kinds of optimizations that could cause this problem.
It also offers a nicer interface that's easier to manage.