I disagree. Yes, different permissions can be granted on a synonym than on the underlying object. But there's no real point to that. If you're using actual security, like minimum-needed-permissions on a login+user, then there's no point to using synonyms as a security layer. Views can actually allow for row-level security, simply by joining to a "login permissions" table. Synonyms can't do that. Views can allow for column-level security by being defined as something other than "Select *" in the Select clause. Synonyms can't do that.

Basically, synonyms allow for name-obfuscation. That can be a very useful thing, no doubt about that. But it's not a security measure. It's a coding tool, not a security one.

If the sole purpose of views is to obscure table names, that's its own form of useless waste-of-time engineering, and it also doesn't actually enhance security at all. I've seen databases designed that way, where every table had to have a "Select *" style view defined on top of it, none with a Where clause that did anything, and application code was only allowed to access the views. This is universally done out of ignorance of actual database security, and has no functional purpose at all. It's a "we don't know what we're doing, but this makes us feel safer" type thing.

Feeling safer has its own benefits, of course. It also has major drawbacks if the safety is purely an illusion.