I think "set -e" in bash should become common on the same level, it's pretty rare that you really want a script to continue after an unguarded error return.
Given that, I think it's nice to be a bit more explicit, as it means the person who reads your script to copy and paste a bit out of it is more likely to learn something new in the process.
Not that the copy and paste approach to learning a language is good, but that's how these things typically go in practice.
#! /bin/bash -eu
If i was more selective in my use of those flags, then i would agree that the long forms were preferable, for the reasons given.
% bash script.sh
As you can guess, I've done this by mistake. One case is after transferring or unarchiving files where execute flags get turned off by mistake. Or using utilities, like job schedulers, that are tricky in whether they run the script as an executable, or via a shell interpreter.
Try googling for that if your Google foo is weak. "shell script dot"? "bash dot"? (edit: it seems Google search has gotten smarter or probably has an improved profile for me since this time it actually points to somewhat useful stuff; last time I searched for this was 8 or so years ago)
But "set -e"? Oh yeah, I use that all the time. It also has the benefit of being the same name as the command line option. That's especially useful for "set -x" which I use all the time when debugging bash, especially in the form "bash -x myscript".
I would never say "tar --extract --file" either–it's just not done.
Anecdotally, I've nearly always seen "set -e" in bash scripts I've worked with over the years (if the option is there at all).