I beg to differ. Many beans in Spring are compiled "dynamically, on the fly" as you say. Case in point, nearly any bean that is proxied in any way- be it for WS-* support, lightweight remoting, invoking an SLSB, or because there is AOP being applied to the bean- that proxy is created dynamically using either CGLIB or JDK dynamic proxying. In either case, the result is bean and can be treated just like any other bean. This means that it itself can be proxied.
In the case of the Groovy bean in particular, you would find that lang:groovy is just some syntactic sugar around a GroovyScriptFactory. The bean that is produced implements all Java interfaces that are specified in the script, and should be eligible for proxying if the pointcut expression in question specifies that is the case.
You're quite incorrect in saying that this isn't supposed to work, and in fact, if you read the links I provided, you will find that not only has this issue been reported before, but Juergen also acknowledged there was an issue and corrected it. This seems to be a recurrence of that same issue.
Re: the classloader issue. You have hit the nail on the head as to why this doesn't work. In my case, the GroovyClassloader is a child of the WAR classloader. As such, AspectJ weaver- also loaded at the WAR level- has no visibility into the bean in question (which at this point in the lifecycle is compiled). Again, it seems this is the very issue that had already been addressed once before and is now recurring.