It's also very easy in many languages to use exceptions for non-"exceptional" control-flow even though they aren't really meant for that.
The biggest challenge with error -- or exception -- handling is that most callers are not prepared to deal with something other than success. So the safest thing for them to do is push the failure up, with the expectation that somewhere higher will be equipped to deal with it.
If you take TFA's CopyFile as an example, there are plenty of scenarios where copying a file would be part of some complex process. If the file copy fails, it probably indicates either a logic problem (bad path, empty filename, something) or an OS level failure. Either of those cases cannot be dealt with at layers close to the CopyFile call.
From TFA example, the guard only eliminates the if err != nil { return err }.
This is a bigger problem than can be solved with syntactic sugar. And from my perspective, it is why exceptions exist. If you merrily go on your way in some other languages and try to copy, but that fails, it will generate an exception. If you don't explicitly handle that exception in your calling function, then it will bubble up. If somewhere upstream expects this possibility, it can be designed to respond to a specific type of exception and do something reasonable about it. But your calling function, down here at a low level, will not have any clue what the business logic behavior should be if the CopyFile() fails.
An exception is something unexpected, unanticipated, exceptional. It's totally fine to crash on it. Running out of memory is a good example.
An error is something expected, a less probable but anticipated result. A request timeout is a good example. It's important to have a nice way to process it, and to take an action other than crashing, say, to retry.
In this regard, `guard` is a nice proposal: it explicitly shows where we are willing to crash (like `!` in Typescript or Rust or Kotlin), while staying perfectly backwards-compatible and not requiring any rewrites. It's not perfect in other respects though; I liked the `try` proposal better.