Of course the users who are fine with it won't bother deleting it. That's the point though - what does the majority lose if the UI is packaged separately? Nothing, other than a tiny inconvenience of clicking install on a second/third package. What does the user who DOESN'T want it have to do? Or do they not matter because they're a minority?

One of the advantages the CSSU brings (or at least is supposed to, I haven't checked if it does yet), is that you can go and get rid of a preinstalled "firmware" package that you don't want and don't need, without it throwing dependency errors when you go to update/install anything else. If the .deb / apt-get / dpkg system provide for a way to install them with the CSSU install/update and then delete them without it throwing dependency errors, I say go for it. But far as I know, it only allows for dependencies, and "recommends" which don't get installed near as I can tell anyway (at least through FApMan, never noticed when using HAM).

Editing the power menu is a different extreme of the same concept - there are ways to tweak the UI in the official firmware releases. Because users wanted easier control, people wrote GUI apps to automate/simplify that tweaking. I think the same can apply to the CSSU - some of us are fine not using ApMeFo to make folders in the menu either, or editing our themes without Theme Customizer, yet that's not being pushed to the CSSU. (The reasoning is similar: you have customizable features, people want GUIs. If you think power menu is a bad example, find any number of other customizable things. The overwhelming majority of them want the GUI way. But you don't stick all those things into the CSSU, so why stick it in for features just because the CSSU happens to enable/add them?)

My problem is that not including it causes merely a small inconvenience for one demographic. Including it causes a pretty large inconvenience for another demographic. I think the former demographic needs to be exponentially bigger than the latter to justify that.