Instead of trying to get every CLI tool in existence follow this standard, it makes much more sense to put this support in the terminal emulator or shell. Both can know what process is in the foreground and can strip color or let color through based on a user-configured whitelist/blacklist.
I think the main reason for disabling color output is the programmatic use of the output. It is easy to remove color within pipes (c.f. https://stackoverflow.com/questions/17998978/removing-colors...), however quite cumbersome to clean the output of each potential program just to make sure nothing breaks.
I guess the terminal should not start putting hands into this game since stdout is generally assumed to be binary (not even text).
That's already a solved problem though, with a different solution - programs should be checking `isatty()` and not output escape sequences if it's not going to a real tty. That's how `ls` can display colors by default but still not have them show up if you pipe `ls` into a command.
This page seems to purely be about interactive use with no color.
The isatty() check is obnoxious when you do want to preserve the control chars and can't force it on.
That's a pretty niche case, you can force it by either allocating a pseudo tty or using LD_PRELOAD with an isatty() shim that returns true.
I only ever had to do it once (using LD_PRELOAD) because there was an insane vendor binary blob that would return "SUCCESS" in green/red depending on if it passed or failed. When isatty() returned false, it was impossible to tell if it passed or failed, but the software was pure garbage.
I don't entirely agree. When I do want colour (generally because I've taken the time to configure the program suitably for it), then I usually still want the colour when I pipe its output through a pager. `diff` is the canonical example.
Edit: Another comment¹ points out pipetty² as a workaround, so I learned something useful today.