When I first read about the on-line mode in Aspectwerkz I too wasn't keen on the idea. But it does offer one tremendous advantage, you can test AOP on your existing code base by starting your app server with the 'aspectwerkz' command, the rest of your development methodology (build scripts etc.) remain exactly as they are meaning that AOP can be added in a non-obtrusive way.
The idea of controlling the classloader is not unique to Aspectwerkz, the JBoss AOP implementation also requires control of the classloader (see Bill Burke's article http://www.onjava.com/pub/a/onjava/2003/05/28/aop_jboss.html for more info). But Aspectwerkz can run in off-line mode which is my preferred mode. This is similar to AspectJ, you compile your Java classes and then perform the weaving which manipulates the byte code of your java classes.
Which ever method you chose is up to you, the point of this article wasn't to push Aspectwerkz, I was trying to show how AOP can allow designers and developers to create much cleaner architectures in less time. Cross-cutting concerns usually translates to "repetitive coding", and surely it's better practice to spend your time designing and coding than hand-coding thousands of lines of logging code.
When I wrote the first draft of this article I sent a copy to Jonas to have a read to make sure he was happy with how it had been written. When he saw the first draft he commented that AOP shouldn't be seen as a magical process that works behind the scenes. The fact is that AOP can be used to vastly simplify a system's design and reduce development time, perfectly complementing OO rather than providing a mechanism to patch a poor OO design.