Having used isatty in some of my CLI programs to alter the behavior depending on whether STDOUT is a TTY, I see the appeal. It allows the program to do the best thing depending on how it's being invoked.
However, more recently I've grown skeptical. It leads to surprises, and if a person isn't familiar with the finer details of file descriptors, they may wonder why piping a program changes its behavior. I think this example of someone shooting himself in the foot with pwgen has convinced me never to do this again.
Yeah, that's a hard one. Of course, there are strong arguments for "sensible defaults". But here is how it went :
First, I used pwgen to generate temporary passwords for new unix users. I read the man page at that time, probably saw the mention about different behavior regarding output capabilities and thought : "nevermind, this is not my use case". Years later, when I decided to pipe it, I thought I already knew the program, and certainly not thought : "hey, let's check the man page again to see if the behavior may be altered on a pipe". Especially since I did not think it was a big deal, I was not putting that in a codebase, I just wanted to generate a random password to upload gifs or something.
And that's the interesting thing : should I have wanted to put it in a codebase, I would have read the man page again carefully.
All of this points to one conclusion : consistent defaults for end users are more important than sensible defaults for developers. You can expect developers to pay special attention, so that's ok to alter behavior for them through flags rather than detection of what stdout is plugged in.
However, more recently I've grown skeptical. It leads to surprises, and if a person isn't familiar with the finer details of file descriptors, they may wonder why piping a program changes its behavior. I think this example of someone shooting himself in the foot with pwgen has convinced me never to do this again.