I actually just completed a project to completely re-work the objects within Dundas which (when I inherited it) were named ad-hoc and in only a handful of folders.
For data cubes, I took the technical route since only Dundas-savvy people in my company will be changing much at that level. I built folders first by source (since we pull data from a half-dozen systems each with their own data connector), then made sub-folders to indicate what step along the data path the cube exists. For example, cubes that pull directly from the data connectors have their own sub-folder, cubes that filter/process that data have a 2nd folder, cubes that process PROCESSED data have a 3rd folder, etc. It’s daunting to look at at first, but really saves my time when I’m tracing data back up-stream AND when I’m trying to figure out if I already have an existing cube that does what I want it to do.
For metric sets, I flipped over to an end-user perspective. Again I have my first level of folders based on the source of the data, but then I built folders based on what’s actually being displayed - data label for something that returns a single number, table, histogram, etc.
Finally, for dashboards I put them in folders based on their primary usage. It doesn’t always work as dashboards are versatile, but it does the job for the most part. (Wallboards for dashboards we have on screens around the office, Reports for dashboards that are e-mailed on a schedule, etc.)
Beyond all of that, the best advice is to ask yourself if the name describes the content to someone that just walked in the door. When I’m training people on our Dundas environment, I bring up the example of MSCountNetworkingTicketsEnteredYesterday. Yes, it’s a long name, but it tells me everything. It’s a metric set (a habit I picked up from VB coding), it’s a count, it only looks at Networking Tickets and it only looks at Date_Entered of Yesterday. Clear as mud. Don’t be afraid of a long name if it takes 6 or 7 words to describe what’s happening.
Best of luck!