Better protection against failing to protect tables with RLS

I was recently surprised to discover that the default for tables that do not have RLS enabled is full read-write access to unauthenticated users. When creating a table through the web UI there is a warning if you do not enable RLS, but when using SQL there is no warning, and tables have RLS disabled by default. I struggle to think of any use case in a real publicly deployed application for intentionally exposing a public API to delete or overwrite all data in a table. Given how easy it is to do this accidentally, I would predict that the vast majority of your users' projects that expose their anon public key and have left RLS off on one or more tables have done so accidentally and have a serious security hole in their app. Is some kind of safety net warranted? Potential mitigations include requiring RLS to be enabled in order to access a table through the API, or enabling RLS by default and requiring it to be explicitly disabled. Or if those go against the grain of the w…