The real pro tip is: don't use bash if it's not trivial to read
Plus, the POSIX specification for the shell is significantly more concise and clear than the manuals for Bash, Zsh, etc. See Shell & Utilities -> Shell Command Language at https://pubs.opengroup.org/onlinepubs/9699919799/ I know exactly where to go if I can't remember the difference between ${foo:-X} vs ${foo+Y}.
Also, don't run a command that directly overwrites a file unless you know it's going to succeed. A temp file lets you atomically replace the file only if the download succeeded. And a cleanup trap helps clean this up in the event of errors. Finally, you can die on unset variables or errors (cleanup still works) and you can enable tracing if environment variable DEBUG=1 was set.
#!/usr/bin/env sh
set -eu
[ "${DEBUG:-0}" = "1" ] && set -x
cleanup() { rm -f /usr/local/bin/mybinary.tmp ; } ; trap cleanup EXIT
panic() { printf "$0: Error: %s\n" "$1" >&2; exit 1; }
mkdir -p /usr/local/bin
[ -e /usr/local/bin/mybinary ] || \
wget -q -O /usr/local/bin/mybinary.tmp "$url" \
|| panic "wget was unable to download '$url'"
mv -f /usr/local/bin/mybinary.tmp /usr/local/bin/mybinary echo Option -n invalid # OK
echo -n is not valid # Uh oh
printf '%s ' -n is not valid # Always okay
Generally you should use printf because of its consistency. For a simpler example of OP's: panic() { printf '%s\n' "${0}: ${*}"; exit 1; }
Is fine. I don't see the need to pass a format string to your function. Just call: panic "${download_url}: unable to download"
Another common style guideline is to include context for the diagnostic, often prepended. For example,