Really.
More available colors make it easier to develop coloring that looks much less christmas tree.
Why? Because you have a wide choice of shades and soft colors.
For example, CF now colors received damage in very bright red color. In my highlights I specifically used much less bright color for that (to protect my eyes). With ANSI color codes you don't have a lot of choice. It's either: dark red (which looks bad) or bright red. With custom colors you can go any color inbetween.
When there are many available colors you can pick different colors for different types of thing and yet have them readable.

Moreover, in my case, I have a set of variables where you can define each color, so you can go with shades of gray, for example, for each highlight. of just disable several classes/types of events you don't want to hightlight (by making them default text color or just disabling a whole class).

Talking that "supporting" my system is dumb because my coloring looks too much for somebody that is what is really dumb. My coloring isn't the constant set, you can redefine it as you would like.
Supporting it has nothing to do with good or bad coloring. It is not about coloring at all. My request was to make mud output more conforming. More regular with less exceptions.
I will give you a simple example. Assume you asked sombody to write some text report about something (let's say the average salaries in cities). He can come with two variants:
- write very randomily formatted text
- put it in a nicely structured table.
I definetely will prefer the second variant. Why? Because it's easier to read and follow when similar concepts look alike and structured.

The same happens with CF output. Notice, it has nothing to do with roleplay. It's just a request to print similar stuff using similar formatting because it's much easier to follow it. Whether I choose to color it and which color I pick for that is completely different and unrelated matter.
For the very same reason I don't really like many parry/dodge/shield messages that were implemented by Valg some time ago. I need to read CF information about my defensive move type and I can use my own imagination to add that variaty in my mind. I don't really like to be forced to read those 40 types of dodges that happens once in 20 regular dodges and serve the only purpose: confuse me.
Plus, in reality, people hardly have time to read them all in fights.

Specifically about combat rounds highlights:
I hightlight several things:
- my damage to opponents. Because it helps me to see what I'm hitting and how much.
- Opponents damage to me. Easier to track what is hitting me in spam.
- my defensive moves. Because sometimes I fail to notice when people redirecting on me or assist or anything like that but I haven't receieved any damage yet (I parried it all). Highlighting defensive moves makes easier to follow that stuff.
- third party damage. I don't really highlight it, I use default CF damage color instead, but I hightlight it in my logger scripts.

Combat color picks explanation:
1) I had to a pick a soft color for hightlighting my moves. I decided to go light cyan because it is much less aggressive than ANSI cyan or Yellow. And it is close to white while being easier to notice.
2) For opponents damage it is light red. That should be some kind of alarming stuff, so red is natural. But bright ANSI red isn't good for that, so I use soft red/magenta.
3) My damage. It's something that shouldn't be very alarming. Thus I pick some neutral color (Yellow) that is easy to notice yet not very aggresive. If you remove red colors (everything is good and you're winning) you will have only silver (default text), lightcyan (your moves) and yellow (my damage) in you output and the combat rounds will be more or less monochrome looking. It's not really fun to read all combat rounds painted in different shades of red. Red on black isn't great coloring scheme, though DurNominator may like it.

For other types of messages I use different colors as well.
If you dont want to hightlight a particular set of events you can just turn them of instead ot asking Zulg to break consistency in CF output.
For me, I prefer to hightlight many types with different colors. It makes easier for me to follow what happens and how I should react.
Examples:
- healing is purple. If I see purple I know something bad about me is cured, so if I don't have time to read I can just skip that line
- successeful skills "gold". This is consistent with my damage color. Some neutral color to let me know that things happen as I planned to.
- failed skills/spells - a shade of blue. Here I know that some skill/spells needs to be used again. But I don't want to go red or something.
- moving. People arriving/leaving. This is White.
- Some kind of orange marks all dangerous #### to me like "hold person", bash, etc. So in a combat I know what to read first. If DurNominator doesn't care about being bashed - good for him, he can disable that color.

Plus you miss another part of my system that is small but very important:
It's the prompt splitter.
CF isn't good at marking prompts with special ANSI codes that many clients recognize. Thus, if you spammed several commands and then receive several results together your text will be joint with prompts which makes it look ugly. And clients can't really distinguish it because it is just a text.
There are two solutions to that:
- mark prompts on the server side with GO-Ahead command that many clients will recognize. This is actually request to Zulg (though I made it severals years ago and got rejected).
Some reading about it: Muds and telnet
- use prompt splitter triggers on the client's side. This is much less robust implementation because it requires for a client to parse prompts that can be very different.

If you don't understand what about I'm talking below are two examples of badly formatted text from CF because of this prompt issue and fixed output:

CF output:

<prompt> Your dirt kick misses
round text

Fixed output:

<prompt>
You dirt kick misses
round text

Another common example. When you spam directions the situation where you spammed several commands is quite common. Thus almost all the time room descriptions are joint with incoming prompts:

CF output:

<prompt> Market Square
description

Fixed output:

<prompt>
Marker Square
description