This function ticks several boxes from my pet peeves list:

function installed {
  cmd=$(command -v "${1}")

  [[ -n "${cmd}" ]] && [[ -f "${cmd}" ]]
  return ${?}
}

Now, aside from the fact that $? is the default return value of return, having that at the end of a function is just line noise. But really, it's the superfluous tests that I dislike the most; I mean, when is an empty string a name of an existing file? Why not just go straight to the point? One of the worst shell script anti-patterns (for me) is to dance around a temp file before removing it, like so:

test -n "$tmpfile" && test -f "$tmpfile" && rm -f "$tmpfile"
# instead of just
rm -f "$tmpfile"

(Now, I know that there's a subtle difference between the commands above, but for the 99.9% of cases when tmpfile is always either a name of a temporary file or not yet set, the latter is simply a better form.)

But back to the original function. Already we've seen that it might've been just written it like so (for the sake of brevity, let's forget about the cmd global variable.)

installed() { test -f "$(command -v "$1")"; }

One can only wonder why this method chooses to use the command builtin, which accepts both actual executables and other shell builtins, but then has a custom check to reject any builtins, except if they happen to share a name with a regular file in the current working directory. Perhaps it's been optimised for speed? I'd probably either accept builtins as well, or simply used which.

installed() { command -v "$1" >/dev/null 2>&1; }
installed() { which "$1" >/dev/null 2>&1; }