Some random trivia about the implications of this change you cite, and then about some related things...
I arrived on scene with MACLISP in 1977. As an undergrad, I managed to get assigned a desk and console in an office with Guy Steele and JonL White (who wrote this announcement). Having such folks, and others, handy made it easy to ask questions. I wrote The Revised Maclisp Manual (later webbed at https://maclisp.info/pitmanual) a couple years later in order to share what I'd learned.
In '77, DEFUN worked exactly like what you show here, but with some nuance that may have been there from the beginning or may have been added later:
One of the important but easy-to-overlook things about DEFUN, as described there, is that when you compile a DEFUN in MACLISP, it puts the compiled definition in the SUBR or LSUBR property, and when you compile DEFUN FEXPR, it puts the compiled definition in the FSUBR property. So you could write DEFUN and it would work either interpreted or compiled. This is because when you funcalled something, it looked for a definition in any of the SUBR, LSUBR, or EXPR property. But had you used DEFPROP, there was a complex philosophical problem because really the compiled version of (DEFPROP (LAMBDA ...) EXPR) had to willfully turn into (DEFPROP <compiled-lambda> SUBR) or (DEFPROP <compiled-lambda> LSUBR), even though the definition CLEARLY asked for a particular property. DEFUN hid such implementation detail, which was just semantically messy. Much of MACLISP was similarly messy.
The biz about SUBR vs LSUBR, for those who don't know is that there was a thing called a LEXPR which was obtained by (LAMBDA N-ARGS ..body..) where the argument received a number of args and you had to call the ARG function (it was function-like but really a special form) to get the particular arg. That was how you could receive variable numbers of args before &keywords were invented (and also how &keywords were implemented at the low level in Maclisp even after the DEFUN& macro arrived on the scene). A function like (LAMBDA (X Y) ...) compiled to a SUBR but a function like (LAMBDA X ...) compiled to an LSUBR. Except any function of -- if memory serves -- 5 or more args got compiled as an LSUBR even if it had a fixed number of args. Again if memory serves, this was an issue of the SUBR function call sequence needing to use registers and only a fixed number of registers were allocated for args, so if the number of args exceeded that number, the LSUBR calling sequence was used.
MACLISP did not worry excessively about whether compiled code and interpreted code had precisely the same semantics, so the fact that
(DEFPROP FOO (LAMBDA X X) EXPR)
(PRINT (IF (GET 'FOO 'EXPR) 'YES 'NO))
printed a different value interpreted and compiled was not something that surprised many experienced programmers.
Of course, there were other compiled/interpreted differences like that interpreted (LAMBDA (X) (F X)) would special-bind X, while compiled it would not. This is short of saying the X was lexical. There were no closures. But the binding was not available to called functions like F in compiled code even though it was in interpreted code.
The realizations that these various language features mattered at all, and needed to be consistent, were gradual. MACLISP was as much a testbed for new ideas as a language itself. It was a big deal thing (and even very controversial) that Common Lisp had lexical variables.
(Insert obligatory reminder that MACLISP is nothing to do with the modern macintosh. This was long before Apple existed. Project MAC at MIT was something quite unrelated.)
