Thanks for the response Cole.
Yes it's almost entirely about #1 clutter in my view. Not really a good option to hide stuff for for security, though for some use cases there is potential for #2 using pins to feed off the existing access policies - e.g. only allow users to access to certain data sources based on tokens stored in pins (one per data source) to which they have access, but which wouldn't necessarily need to be seen? I'd guess that type of setup would be pretty easy to maintain via the dashboard (by the pin owner) or the API, by updating the token as required, or by removing access.
Of course the security side of this could be done better by using an external source of data-level permissions (though perhaps this is detrimental for RStudio - im sure users would be really tied-in if their data-level permissions were also handled by Connect!). Alternatively a large number of groups could be used.
I could mirror my theoretical #2 use case without clutter by creating pins as a system user (though without care this will break if permissions change).
I can't get around #1 clutter caused by visibility of public documents I think?
For those public docs which only exist to be embedded in a website perhaps JWT token OAuth authentication from the website host would allow it to embed the app under its own username & remove the need for the app to be publicly listed on Connect without going through the user-level OAuth flow? Not thought that one through properly & I don't have huge experience here, so maybe I'm way off. Hiding it would be much simpler!
Anyway, it'd be interesting to have a decluttering option for some use cases, & (if thought through properly) it might open the door to some security uses too.