AOP is an idea that sounds wonderful as a concept - "Hey wouldn't you love not to be peppering your code with logic unrelated to the business logic in your code?"
Great idea...however, every implementation I have seen is terrible. It makes code nearly impossible to test and audit and, in addition, creates a whole other set of code that needs to be tested and audited.
Taking the example at hand. From the first function I have a clear idea of what to expect, when I should see logging and what the failure cases and responses are.
Now instead of a 1 line log statement, the article proposes the 7 line meld definition is much cleaner. Where does this code live?
Another 7 lines to track the length of the call, opposed to 3 lines in the function. And now I have a hidden entry to my function - before the calling path was clear...calling dial() meant I called dial() now calling dial() means I actually call some random function which, assuming it has been written correctly, calls dial()
The error handling is possibly the one redemption here, but still - OO provides you with the tools to encapsulate retry logic just fine without resorting to AOP.
I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now.
Nice write up though.