It's a nice example but when would you actually want RLS in the database? In practice you'd want to validate phone number formats etc, so between this and adding a "WHERE row_owner = X" to every query doesn't seem that different.
This will make it easier to replicate with say iPhone clients running Sqlite. Everyone can write to the same db, but only see their own stuff.
You could dramatically reduce SQL Injections by giving each user their own database login with limited rights. Login to web site as foo, which connects you to database as foo. With RLS you can do less damage.
Or let management connect directly to the database via Excel. Use RLS to prevent lower managers from seeing upper managers' salaries.
Inside governments, there are often individual pieces of data within a larger dataset that are protectively marked. For example, fake identities created by the government, identities of prominent people (like members of the Royal family) or maybe even people at high risk of identity theft like bank managers.
Your normal app just thinks the records for these people are missing or knows that they are present but can't access all of the data for them. These people have to make special arrangements to eg, apply for a driving licence.
The way it works in paper processes is that normal caseworkers will get the file and see that it's protectively marked and then hand over to a caseworker who has security clearance.
Obviously it depends on how much of your problem ___domain you're reifying in your database but it can be a nice option, particularly as part of defence-in-depth.