The explanation here is related to the same situation found in the other question... the expression here is at least potentially ambiguous, so it can't reasonably be validated at define time. It could refer to something that's not yet defined.
MySQL validates the syntax of stored procedures at define-time, but it doesn't validate anything that's potentially ambiguous or things that could become valid by the time the program is actually running.
In a stored procedure:
SET foo -- definition rejected if 'foo' is not a valid local or system variable
= bar; -- definition rejected if 'bar' is not a valid local variable
-- potentially ambiguous, probably intended to be a column name if 'foo' isn't a variable
-- could be a reference to a not-yet-created or altered base or temp table
UPDATE buzzfizz SET foo = bar; -- checked for syntax only, server assumes you know best
The tables referenced in a stored procedure don't even have to exist when the procedure is declared, or could have a different structure when the procedure is run... after all, you can create tables (base tables and temporary tables) within stored procedures. If a procedure could only be declared against already-existing objects, this would be a significant lack of flexibility. You can also "mask" a base table by creating a temporary table with the same name, which would have messy implications here.
Stored functions and events abide by the same general rules, although things are a little different there since these programs do have differences from procedures... for example, you can't create a base table within a stored function, because stored functions aren't allowed to implicitly or explicitly cause a
Triggers are somewhat different, because they are parsed and cached as soon as they are declared, so if their definition doesn't match the table they're defined against (i.e., referencing a nonexistent column in the table via the
OLD alias), the trigger is rejected... but references to other tables are not validated, since the other table might not yet exist and things that could be "column names" could indeed refer to columns or could refer to be other objects.
Views are somewhat different. They're validated at define time, and the referenced objects have to exist. That's why
mysqldump generates SQL statements to create a dummy table with the same name and approximately the same column definitions as each view, only to later cause those tables to be dropped and replaced with the view itself. If not for this, views couldn't be restored from a backup if they referenced other views that did not yet exist. You can change the underlying objects out from under a view, which will cause an error, later when you try to access the view... but you can repair a view that you've broken in this way by putting the table back into its original condition. Views, of course, have no local variables and can't create or alter tables or manipulate transactions.