This is an accurate answer, but it misses the point that the design implemented is an anti-pattern. These permissions need to be assignable privileges through Unity Catalog, not managed by "owners".
Here are 3 example bad outcomes of the design:
One: we have Groups A and B working in a given schema. Tables in this schema are "theirs" and we want them to create, update, delete, etc. We also have an admins group C, and a group for service principals D that need to have permissions. Instead of assigning the appropriate permissions to each group and being done, we have to create an additional Group E containing these groups to be the "owner" of the schema. It's not a big deal for one schema, but having hundreds of schemas and dozens of combinations of "owners" adds up to a lot of hassle.
Two: Perhaps most impactful, we want users to be able to create, edit, modify, and delete tables within a schema, but not necessarily to make any changes to the schema. To do this, we have to make them (or their group) owners of the tables in the schema. Our solution has been to make these users "owners" of the schema so that they can update the "owner" of the tables in it as needed to delete or update DDL. The "owner" permissions on the schema provide expanded permissions to it that we don't really want to give them, but the only alternative is to have our admin team manually update ownership on tables and/or do the DDL changes and table drops for them, but that's just too onerous.
Three: For many schemas we want to allow editing in our development environment but we want to prevent users from manually changing these in our testing or production environments. As "owners" have privileges on the object, we can't have the same owner set in all environments, which becomes a maintenance headache for anyone using automated deployment tools like Terraform. This requires putting each owner group in a variable to manage the difference between environments, which is doable but messy and SHOULD be unnecessary.
These headaches would go away by having "EDIT DDL" (or cover this with MODIFY) and "DROP TABLE" permissions on tables, and inheritable from the parent schema and catalog. Similarly DROP SCHEMA, MODIFY SCHEMA, DROP CATALOG, and MODIFY CATALOG permissions are needed and just make sense for the UC permissions model.
