set -e is unreliable

…but since most of the failure modes are false positives (i.e. a script will errexit when it could have continued), you should use it anyway. The stated alternative of "perfectly know when a command should abort the script on failure and add error checking there" is an obvious non-starter of the "just code better" variety. Instead, you should both add your own error checking and use set -e to hopefully catch some of the cases where you missed or misimplemented a check.

The real lesson that should be learned from every shell tutorial is that you should not write nontrivial programs in shell. There are too many weird behaviors, edge cases, and gotchas to end up with anything reliable, and the failure modes can be hilariously catastrophic. It's useful for scripting (hmm…) what would otherwise be a repetitive manual task at a terminal, but you should jump ship to a language like Python earlier rather than later.

As an aside, there was substantial discussion on lobste.rs about the hashbang, with many people advocating for /bin/sh instead of /usr/bin/env bash and most of the counteradvocates citing bash language features. (n.b. don't use /bin/bash, though. That's non-portable, and it's non-portable to some surprisingly unobscure systems.) I have a different position: your hashbang should always be the shell you wrote and tested the script with, because otherwise you are quite likely to introduce incompatibilities with the explicitly specified shell in the hashbang. (In particular, bash in POSIX mode will happily and silently accept a large number of bash-isms.) Unless you're actually writing and testing the script with e.g. dash, don't lie in the hashbang; the cost of making somebody install bash to run your script is significantly less than the cost of making them figure out what shell it actually targets and then install that shell.