This may have been a bad example, but I meant for this to 1. Give a simple example of how attributes can be used, and 2. Mitigate place stealing disagreements (they happen a lot!)
I don’t think this is a rehashed concept though and I don’t think it’s likely that most exploiters will spend the time to remove this type of thing since it serves as no obstacle. It’s not any form of advertisement or anything and it’s unlikely people will search for this in a leaked place. It’s mostly for proving you own a place.
I kind of hadn’t thought about the memory footprint of this. You make some good points with that. To reduce memory it would make sense to keep things small. My code example is rather bad in terms of memory usage. I’m fairly sure that the data in the attributes actually has a similar footprint to how you’d traditionally store this type of data though so I’m not sure how much worse this is than storing content in a module.
Here’s my counter argument to this though,
Personally, I don’t ever worry about memory and I’ve legitimately never needed to even with hundreds of instances all storing data on the server. There’s almost no performance cost to storing a lot of data and as long as I properly handle everything my clients will have little to no memory footprint. Keeping data on instances that aren’t replicated (ReplicatedFirst ironically is included in this list, as well as CSGDictionaryService).
So there’s no client-side memory footprint for CSGDictionaryService, ReplicatedFirst, ServerStorage, and ServerScriptService, etc attributes. This brings up an interesting idea as well. By using non replicated instances such as Cameras as storage objects (which are easily creatable) you can safely store server-only Attributes! I’ve tested all of these services/instances and they do indeed prevent attribute replication just like any other property changes. And the client memory footprint isn’t effected at all!