The "sane UI" in this case is one that has already existed for years, and it's the user intent of dropping a file into an application to give it access.
"For years", simply opening an app implicitly gave it access to most of the data on your hard drive. Regardless of whether you opened or dragged in a particular file.
In Catalina, Apple wanted to restrict this. As a consequence, in the initial release of Catalina, you could drag a file from your desktop into your Terminal, but your Terminal would be unable to access the file. Which of course is terrible UX!
So what Apple did in this update is give back the behavior you're describing: dragging a file into the Terminal implicitly grants the Terminal access. But unlike in old OS's, the Terminal doesn't suddenly get access to most of the other data on your hard drive as well.
Unfortunately, in order to walk that fine line, Apple had to add an extra, undocumented file attribute. And because Apple policy is for anything TCC-related should be SIP-protected, that attribute is protected by SIP and cannot be manually edited. And because a UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either...
Apple's intentions with all of this absolutely make sense. The problem is that good intentions don't matter if the execution is flawed.
Why would this be a complete nightmare? There's no way to override a permission that's been granted to your ancestor - so why shouldn't the OS be able to remove the flag when you remove the permission in Settings? Why shouldn't the OS be able to maintain the invariant between the permissions dialog and the on-disk representation, given that the on-disk representation can only be set by the OS? That's just sad.
You could put it in the individual file's get info pane, but more users open that pane than know what the Terminal is.
This is the kind of setting you'd want to control via either the Terminal (ironically) or a third party app. But Apple has decided only Apple-supplied software with a UI is allowed to control TCC.
I'm replying to my own post many hours later, because something just occurred to me:
There’s no reason the Terminal or a third party shouldn’t be able to remove this attribute. Just restrict adding the attribute!
What happens if you want to revoke a kext? Delete the entry from the SQLite DB? Nah. Guess what, SIP prevents any and all deletions from that DB. You have to disable SIP to revoke a kext's permissions. And because the signature is not a hash, but instead a two-part vendor/product, it's entirely possible for a malicious version of an existing kext to be released that is then permitted by the signature.
As an admin with security focus, this to me seems completely backwards. I get that Apple don't want to make the permitting operation to be too difficult in the first place, because these are end-users we're talking about, but the lengths they go to in order to prevent the permissions being revoked is downright strange.
Put the access details in the Get Info of the files in Finder.
Citation needed. It is just a list. I don't see the "nightmare".
There are likely many better ways to handle these situations, but I'm not sure I really expect it from the recent Apple. The most recent Apple is recognizing issues (i.e. MacBook Pro keyboard), but I doubt the whole organization has caught up.