$ date +%w
  0
  $ cat foo.sh 
  #!/usr/bin/env sh
  set -x
  set -eu -o pipefail
  echo "start of script"
  echo "start of pipe" | cat | false | cat | cat
  if [ "$(date +%w)" = "0" ] ; then
    echo "It's sunday! Here we do something important!"
  fi
  $ sh foo.sh
  + set -eu -o pipefail
  + echo 'start of script'
  start of script
  + echo 'start of pipe'
  + cat
  + false
  + cat
  + cat
  $

Notice how the script exits, and prints the last pipe it ran? It should have printed out the 'if ..' line next. It didn't, because the script exited with an error. But it didn't tell you that.

If you later find out the script has been failing, and find this output, you can guess the pipe failed (it doesn't actually say it failed), but you don't know what part of the pipe failed or why. And you only know this much because tracing was enabled.

If tracing is disabled (the default for most people), you would have only seen 'start of script' and then the program returning. Would have looked totally normal, and you'd be none the wiser unless whatever was running this script was also checking its return status and blaring a warning if it exited non-zero, and then you have an investigation to begin with no details.

> IMO it's good defensive practice to start scripts with "-e" and pipefail.

If by "defensive" you mean "creating unexpected failures and you won't know where in your script the failure happened or why", then I don't like defensive practice.

I cannot remember a single instance in 20 years where pipefail helped me. But plenty of times where I spent hours trying to figure out where a script was crashing and why, long after it had been crashing for weeks/months, unbeknownst to me. To be sure, there were reasons why the pipe failed, but in almost all cases it didn't matter, because either I got the output I needed or didn't.

> it's preferable to fail with inadequate output than to "succeed" but not perform the actions expected by the caller.

I can't disagree more. You can "succeed" and still detect problems and handle them or exit gracefully. Failing with no explanation just wastes everybody's time.

Furthermore, this is the kind of practice in backend and web development that keeps causing web apps to stop working, but the user gets no notification whatsoever, and so can't report an error, much less even know an error is happening. I've had this happen to me a half dozen times in the past month, from a bank's website, from a consumer goods company's website, even from a government website. Luckily I am a software engineer and know how to trace backend network calls, so I could discover what was going on; no normal user can do that.