Eric S. Raymond, in his guide "The Art of Unix Programming", mentions this principle as Rule of Silence: "When a program has nothing surprising to say, it should say nothing."
His statement probably related to command line applications, but it makes sense for a lot of cases.
It sounds smart but what counts as surprising is entirely context dependent and most programs won't be aware of your context.
E.g. a command line app where you put a subtly wrong switch in that does exactly what it thought you wanted and prints nothing while outputting a 0 exit code is dangerous.
It's about context, of course, but it's not really the program's responsibility to know the user's context. It's the user's responsibility to understand their own context.
A tool should have sufficient interlocks to ensure safety when not engaged, but no more.
I follow your point, however it actually supports mine: An HTTP response isn’t intended to be the output of a command line app. A command line app should take the response from the lower-level HTTP communication and articulate whatever appropriate message to the user, depending on the verbosity level for example. Talking in OSI terms - this is a presentation layer problem, not a link layer one.
TLDW: Most of the Gitlabs outage where they deleted the primary prod and backup prod database could have been solved if they just waited for the command line op to complete - but because of a lack of feedback they thought it had frozen, leading to several other plans which made the situation worse.
His statement probably related to command line applications, but it makes sense for a lot of cases.