The arithmetic instructions could be surfaced as join points. e.g. iadd/isub/dadd/lsub/etc. Join points are really just a manifestation of a bytecode instruction. However, these instructions operate on the stack and AspectJ does not track who put what on the stack, so in the pointcut/advice you would be able to receive the operand values but you wouldn't be able to, for example "match when anything is added to i" because when the join point is constructed we don't know that 'i' is on the stack. And matching based on specific values would usually need to be a done with an inserted dynamic test, because we don't statically know what is on the stack, e.g. "match when anything has 5 added to it" (possible exceptions could be when low number constants are used and so the bytecode has one operand encoded in it, e.g. iadd_1)
Implementation: only a few days to get something hanging together but a lot longer to get it meshing consistently with all the other language constructs. There would be a need to define what every pointcut designator means when it hits an arithmetic join point.
Adding join points is a serious business though as it can cause issues for anyone upgrading to new versions of AspectJ. Their older aspects may suddenly start matching on unintended join points. I think those most recently added were for array construction and those are still protected with an option flag to turn them on (for the very reason that old aspects don't trip over them).
As Alexander says, you can be at the mercy of what the compiler chooses to do in terms of optimization but this isn't anything particularly new, there are cases of this already here and there.
Is it on the roadmap? Not at the moment. We have things like proper handling of invokedynamic and the incoming Java8 language features to worry about.