It matters because the "how" and the "why" are different.

AOP is not the ability "inject a bunch of arbitrary opcodes at any defined point in the optree". Neither is it just the ability to add pre- and post-conditions to a subroutine.

You can have AOP without opcode insertion (e.g. via wrapping subroutines in Perl's Aspect or AspectR in Ruby.

You can have opcode insertion without something being AOP - many macro systems for example.

You can have pre- and post- conditions without something being AOP (e.g. Class::Contract does not allow you to do AOP).

AOP is about creating "aspects" that describe functionality that cross-cuts a traditional OO class hierarchy.

If you're interested you might find some of the early Parc papers useful (Aspect-Oriented Programming and RG: A Case-Study For Aspect-Oriented Programming).