For comparison, since I'm using Emacs with native-compilation:

Interpreted result:

  ELISP> (hn/foo :bar :ignored)

  (closure
   ((y . :ignored)
    (x . :bar)
    t)
   nil x)

This is equivalent to the output in the article. Now, after running compile-defun on the function and calling it, I get:

  ELISP> (hn/foo :bar :ignored)

  #f(compiled-function
     ()
     #<bytecode 0x1f40000a8a1d>)

This is the byte-compiled case, which sadly is not readable for some reason. That said, IELM (Elisp REPL) makes that #<bytecode ...> form clickable (it's a so-called "presentation"), which leads straight to the following disassembly:

  byte code:
    args: nil
  0       varref x
  1       return

After native-compiling via (load (native-compile "file.el")), I get the same output as with byte-compiled case (+/- the address in #<bytecode ...> form), but the disassembly is slightly different:

  byte code:
    args: nil
  0       constant :bar
  1       return

EDIT: turns out it's IELM that's playing games with the printer. If I write:

  (print (hn/foo :bar :ignored))

instead, I get the readable output from the article, in both byte and native-compiled cases. My understanding of the latter is, the closure returned from a native-compiled function is itself only byte-compiled (at least when used in REPL), and the difference in bytecode assembly come from the latter running through a more thorough optimization process.