Warning! Author thinks in Blub ( http://www.paulgraham.com/avg.html ).
More seriously, Ruby's apparent class patching combinatorial explosion of bugs makes a very good case for aspect oriented programming ( http://video.google.com/videoplay?docid=8566923311315412414&... ).
I don't think it makes a particularly good case for AOP myself. AOP is just another, slightly more structured, form of the same thing - a structured COME FROM (see INTERCAL), if you will. The ability to globally append to or modify arbitrary functions in existing code is no substitute for a) limited extension within the scope where the extension is actually used and b) actually coding classes with well-documented extension points, whether Emacs-style "hooks" or some other mechanism.
Regarding AOP, when I saw the video, I thought "OMG! Someone invented OO COME FROM by matching stackframes!". Indeed, a question in the video subsequently alluded to a stack implementation.
Anyhow, although it is possible to write an entire application in aspects, it is likely that the worthwhile threshold for doing anything in AOP is larger than the threshold for doing anything in OO. In trivial cases of OO and AOP the execution overhead is minimal. Furthermore, there's opportunity to reduce overhead when you've got a bytecode implementation. I'll give an example using testing and asserts.
If we had a bytecode implementation which supported aspects and we loaded a test harness, the test harness aspects could effectively add asserts throughtout the code. If you don't load the test harness then the asserts aren't formed. Languages like Ruby are ideal in this situation because the bytecode can be devised such that trivial and non-trivial cases can be easily added into already compiled bytecode. This means that you've got hooks everywhere without forethought and with minimal overhead. Planning ahead remains a better option but its nice to have a fall-through case which scales.