If you have the appropriate policies in place where people are unable to create clusters and only clusters with table access control enabled are available then yes, you've essentially made mount points only available to those that have access to clusters that can use them, or Administrators. That would be similar to disabling mounts and only accessing external data through session scoped credentials and managing access to said credentials through access control lists.

The difference in the two methods boil down to the objects we have available to manage access. Access Control Lists, or the Administrator role + table access control clusters.

Mounting by nature makes it so everyone with access to any cluster that can see the mount point. The method around, as you've stated, is to only have table access control enabled and leave only Administrators as able to access file level data. But then you need to promote a principal to Administrator to be able to access file data, which may be unwanted.

Not mounting and only accessing file data through session scoped credentials allows you to use any cluster type. You can then create a secret scope with access control lists and specify which users/groups have access to the scope, controlling who has access to the file data in a least privileged manner.

Cloud provider notes:

• All users in the Azure Databricks workspace have access to the mounted ADLS Gen2 account. The service principal you use to access the ADLS Gen2 account should be granted access only to that ADLS Gen2 account; it should not be granted access to other Azure resources.
• When you create a mount point through a cluster, cluster users can immediately access the mount point. To use the mount point in another running cluster, you must run dbutils.fs.refreshMounts() on that running cluster to make the newly created mount point available for use.
• Unmounting a mount point while jobs are running can lead to errors. Ensure that production jobs do not unmount storage as part of processing.
• Mount points that use secrets are not automatically refreshed. If mounted storage relies on a secret that is rotated, expires, or is deleted, errors can occur, such as 
• 401 Unauthorized. To resolve such an error, you must unmount and remount the storage.