AOP and code maintainability
AOP is great as it allow us to address common concerns in a uniform manner. However, as the program evolves, there may come a time when the designer may want to change the class or method signatures and behavior, and this may result in an aspect no longer functioning or misbehaving because of changes in design assumption.
In Java, a change in method signature would result in either in compilation error (for dependent type) or immediate class incompatibility during execution. But in AOP, the type binding is loose and there will be a chance some of the incompatibility will be silently ignored and thus causing problems down the road.
This will actually result in less maintainable and less predictable code. I think an effective way to manage aspects will need to be derived before AOP can become a mainstream programming paradigm.