Building an application that is immune to attack defeats all possible attack scenarios, yes. But no application is perfect or immune to all possible attacks, the concept of defense-in-depth is an acknowledgement of this.
Right, but what is presented here is not defense in depth. It's just an additional layer that doesn't address the issue.
The problem at hand is that the PostgreSQL session user has too many access rights and thus the SQL injection is able to wreck havoc.
The presented solution doesn't help because the SQL injection could probably bypass it easily through some other SQL way (custom triggers or rules to intercept the backend pepper or final tokens for example).
The right way to go about this is to create a schema or table per entity combined with authenticating a custom SQL user per customer and setting the RBAC rights for that user correctly.