• Profiles are metadata artifacts, not core data objects
  Unity Catalog’s securable objects (catalogs, schemas, tables, views, functions, etc.) are designed around data governance and lineage. Profiles are considered derived metadata for exploratory purposes rather than a governance-critical asset. So, they weren’t included in the securable hierarchy.

• Workspace-scoped feature
  Profiles are tied to the workspace because they rely on the compute and UI context of that workspace. This makes them non-portable across workspaces—even if the underlying table is shared—because the profile rendering and refresh logic depend on workspace-specific resources.

• Simplified permission model
  Databricks assumes that if you have Manage permission on a table, you can generate or delete its profile. This avoids introducing a new permission type and complexity in the ACL model. However, this does create the issue you mentioned: profile creators cannot restrict other managers from editing or deleting profiles.

Why can’t profiles be shared across workspaces?

• Profiles are not stored in Unity Catalog; they live in the workspace’s metadata store. When you share a table across workspaces, only the table object and its lineage are shared—not workspace-specific artifacts like profiles, dashboards, or queries.