That is only half true. It actually revolves around some edge-cases.

The main use case is if somebody adds some metadata
at the instance level then you need an instance advisor to store
the link to the metadata context and apply the instance level
annotations.

If somebody adds some metadata (e.g. the security domain annotation)
at say the server then you don't need an
instance level advisor but when you create the class advisor
it needs to include the consequences of that annotation.
e.g. add the security advice to the class

If somebody adds the security domain at the deployment level
then unless you know the class is scoped to that deployment
you are also going to need an "instance" advisor
such that the security domain annotation doesn't leak into the
advisor of other deployments using the same class.

So there needs to be some interaction between the scope
(including potentially the classloader scoping if we want to
avoid unnecessary instance advisor construction)
and aop's decision on what type of advisor to create.

For now, I'm only going to differentiate the global (server/domain config)
from the overrides at the deployment/instance level.
The above problem can be optimised later.