I think any time you're making a class and you're tempted to steal the mechanic from another class...
...you need to really examine why what you're making actually needs to be a class and not something else.
Why make a Warlord class with "ally helpful CS dice" and why NOT make a fighting style called "Commander" (or whatever) that gives you the same thing? Why shouldn't it be a Speciality?
If you are determined to that class you're making be its own class, you need to discover its unique mechanic. For a warlord, that might be auras or interrupts or empowering allies or whatnot, but it SHOULDN'T be CS dice.
It's a fighter thing. Fighters deserve their own thing.
I more or less agree with the analysis, but not the premise. Or rather, I disagree that the premise as implied fully accounts for all the choices.
If CS is going to remain a niche thing, without much more scope than it has now, then I agree it should remain for the fighter, for the reasons that you give. That's one option.
Another is that CS manages to grow into something quite robust, as a "marital/weapon" parallel to "spells". In that case, it will be large enough to encompass classes with strong weapon use, in the same way that spells are large enough to cover several character concepts. Being "large enough" here implies "large enough" that a fighter can clearly stand out in CS use.
Alternately, "Combat Superiority" itself might remain the fighter-exclusive bit out of some larger system that grows out of it, used for martial characters. That's a semantic distinction, though. Either way, to expand beyond fighter implies something more than what we have for CS right now.
Finally, in an ideal world, if CS stays relatively small and nothing grows out of it, then there wouldn't be an alternate mechanic because there wouldn't be alternate classes. Fighter will kill warlord and take his stuff. So "warlords" will use CS, because they are built with the fighter class. (This is actually my preferred "clean" solution in several cases, but unlikely to be pursued for several reasons.)
That is, I think a clear-headed analysis of clean systems would lead to the correct answer being in a lot of cases, "We don't have enough difference here to make a new class. So rather than make up some separate widget for this new class, just to be different for the sake of being different, we won't do the new class." Since we are, however, going to get new classes that are different just for the sake of being different, that complicates the analysis of where to reuse or not reuse good bits. Given that limit, I prefer to reuse good bits as much as possible and not use the bad bits.
