What @Constantine said about lexical and dynamic scoping is true, and it explains the difference from Common Lisp behavior.

However, there is something misleading in your question.  This really **has nothing to do with macros**.  Here is a definition using `defun` instead of `defmacro`. Note that you need a quote mark (`'`) before the use of `,function`: `',function`, because you want `'zerop` and not `zerop` (which would be evaluated as a variable).

<!-- language: lang-el -->

    (defun complement (function)
      "Return a function that complements the effect of FUNCTION.
    The resulting function applies FUNCTION to any number of args
    and returns the Boolean complement of the result."
      `(lambda (&rest args)
         (not (apply ',function args))))

    (funcall (complement #'zerop) 0)   ; Returns nil
    (funcall (complement #'zerop) 3)   ; Returns t

    (complement #'zerop) ; Returns (lambda (&rest args) (not (apply (quote zerop) args)))

When you use `',function` you are not leaving `function` as a free variable in the resulting function (lambda form).  Instead, because of the backquote surrounding the comma, the value of FUNCTION that is passed to function `complement` is **substituted** for `,function`, and then quoted.

So when `zerop` is passed as argument to `complement` it is substituted for `,function` and then quoted, producing `'zerop` within the resulting lambda form.  The backquote expression constructs a **list**:

    (lambda (&rest args) (not (apply 'zerop args)))

When you use `complement` that list is evaluated to a function and used as such.

So the *difference* between this approach and the use of free variable `function` in the lexical binding case (that is, the use of a closure that couples (a) the lambda form that has free variable `function` with (b) an environment in which that variable is bound to `zerop`) is that:

1. In this approach there is *no* variable in the resulting form, and

2. The resulting form is a *list*, not a function.

Number 1 means that you cannot use the variable for anything when the lambda form is used as a function, because, *Hey! - it isn't there*.

And it means that unless you explicitly go to the trouble of byte-compiling the resulting form (which is a list, whose car is `lambda` etc.), evaluation is slower, because you are interpreting a list as a lambda form and that as a function - you do not have a (possibly byte-compiled) function directly.

When might you care whether you have a *variable* at the time the function is used? When you need to do something with that variable *as a variable*!  For example, you assign it another value than `function` at some point.  In most cases you do *not* need the variable as a variable - it is enough to have its *value* (in this case, `zerop`) when the function is used.