My brain parses that || as quickly as it verifies the !, and having the actual command at the left of the line is helpful for clarity; FWIW, this is actually a pretty common paradigm in many languages including Ruby--with "or die"--which people generally liked for cute syntax.
Yep, this was a common Perl construct as well, since you could follow "or die" with a custom error string. I used to amuse myself (way back in the Stone Age, when I was in college and didn't know better) by using amusing and unique invectives for error messages like 'or die "you son of a motherless goat"'. Not only did they make me giggle a little, they made searching code for the line that failed a little easier...
What did Larry Wall do to deserve that? Ruby cribbed the "or die" idiom (and others) from Perl because they were useful. At least let him own his good ideas along with the rest of the language.
I mentioned that these days I write Go for a living, which involves a lot of:
if err := thingThatMightFail(); err != nil {
...
}
so I was saying that of course I think lots of `if` statements for error handling are reasonable. (Hmm, thinking back, I learned Go in 2012, and my Bash probably peaked in 2013, I wonder if having learned Go made me more amenable to this in Bash.)
I think a single-line `cmd || die "msg"` like in Perl or Ruby is handy and fine. Or maybe even a two-line
some command that might fail ||
die "Some message that is long enough that it wants to be its own line"
But once it starts getting to have multiple statements that you're grouping with `{ }`, just use an `if` statement. If I were reviewing someone's Ruby that had multiple lines after the "or" in "or die", I'd tell them to just use