I think this is quite risky in a team setup, where a colleague is still working on somethin and it isn't being used yet or hasn't been set as public yet.

Also, unused elements are not really that common in my experience, if you constantly clean up your working area as you go forward. 

For example, just have a look at your TrueChange tab everytime you publish your work, you can simply go through the list, and delete one by one the unused elements with the delete button (not even needed to actually go to the element in Service Studio.

(not talking about unused dependencies, but those can already be cleaned up quickly)  

Sitting amid a messy kithen right now, I'd like to compare it to a Christmas dinner, it is about constantly doing the dishes while you are still cooking / eating.  If you don't do that, your kithen counter has several massive piles and you wish you could all just chuck it in the bin or a giant dishwasher.  But you can't, there might be a left behind present in between the mess.  

I'll reinforce that unused elements are flagged as warnings because there is no way of knowing why they are unused without looking at them. Maybe they are duplicates. Maybe they weren't needed. Or maybe that action took a week to complete and hasn't been integrated yet into the real flow. Was only in a test screen that was deleted before the deployment to QA.

My vote goes in the opposite way. Does not improve performance, only makes people less responsible for their daily work ("the trash truck will take this later"), and causes unwanted stress on people that left something in the middle.

Good Idea, but I have bit different views not supporting the idea.

Cleaning unused elements is the responsibility of the developer. One should remove on daily basis.

Sometimes developer create some element like aggregate or actions during feature development. Actions (client/screen/server/service) user must have created some complex business logic 

It may possible that it will remain there during 2-3 days of completion of the feature. 

If one click may wipe out in progress work of other team members. 

So not in Favour of the idea.

The proposed feature would be a valuable asset for deployment at the conclusion of each sprint, or at any juncture deemed appropriate by the collective consensus of the Development team. At times, the development workload can become so burdensome that routine code maintenance tasks, such as code cleanup, may be inadvertently neglected. In such instances, this feature would be immensely beneficial.

In my professional observation, there have been numerous instances where projects transitioned from one development company to another, and the succeeding team is faced with the daunting task of addressing residual clutter—often in the form of hundreds of unused elements that were left behind. Tackling this issue without an automated system can result in a significant drain on time as the new team has to manually sift through and clean up the remnants of someone else's work.