Here's the problem with feature creep: with every feature that is added for a modder's convience, an extra inconvenience is created for whoever maintains the source code. When mandatory game changes are made, extra compatibility issues need to be addressed for optional features, and additional bugs need to be fixed.
The suggested method for adding the secondary colors feature is to set up a secondary swappable palette color. Now, for the sake of the argument, let's say that the actual implementation of creating a second swappable palette color is actually quite simple—which it theoretically should be, since we already have color swapping code—in this case I don't think there'd actually be anything to maintain at all. Currently, an object's skin color is stored as a variable, which can also be set to SKINCOLOR_NONE to signify no color change. Adding a second color would merely add another variable to this mix. Apart from that and the assumed minor source code change, I can only see one large disadvantage: the need for a default secondary color to be established.
For primary color changing, the default startcolor is green. This usually isn't an issue, except for objects that need green as part of their regular palette—which STILL isn't much of an issue unless it also needs to change the color of a different part of its body. This is why character skins can set their own startcolor, so that the game can change a different color while keeping the green parts intact (such as Knuckles in 2.0). However, no such variable exists for actual objects yet. If a secondary color were to be added, this would almost certainly be a necessity, because it creates the issue of sprites lacking green but containing the default secondary color only changing color when the secondary color is changed. This adds a whole new detail complexity where many sprites have differing values for startcolors and prefcolors. (Though, this whole issue can probably be worked around by having the secondary color feature only apply to players.)
So yeah, that's my way of thinking about the two sides of the argument—again, all under the assumption that implementing secondary colors would not be painfully difficult. If it is in fact not as simple as I think it is, then yes, maintaining the new feature may be an issue.
As Mystic has explained, modders have already created workarounds to allow for the kind of palette changes they need, so there isn't a lot of incentive to work the feature into vanilla. There might be more incentive if someone were to demonstrate a clean, easy way to work in secondary colors that isn't likely to break in the future.
Also, the current method for modding secondary colors in is really inefficient, as you first of all have to make a whole separate set of sprites, and then in game they're rendered as separate overlay objects.
The idea behind my above quote was that adding secondary colors as a vanilla feature is actually the "clean, easy way to work in secondary colors that isn't likely to break in the future." Not that the current method is unclean at all; the only big issue with it is that it requires an extra set of sprites to be made, which is hardly ever really worth doing.