On a general basis, the distinction between just-in-time and ahead-of-time compilation is not relevant to security. One can see things as performance trade-offs. For an application, that consists in a sequence of small instructions meant for the abstract sort-of-Java virtual machine:
In pure interpretation, individual instructions are parsed when they are to be executed, and the parsing of any instruction is done every time that instruction is executed.
In AOT compilation, during a preparatory phase (e.g. when the application is installed in the phone), the instructions are translated into the opcodes that the actual hardware CPU understands. Thus, the "parsing" is done once. Performance is much better, at the expense of a one-time translation done at installation.
In JIT compilation, you get something in-between these two models. Translation is not done in advance, but it is still done by whole chunks (a complete function in one go) instead of instruction per instruction. Compared to AOT, more compilation occurs, basically whenever the application is launched, instead of once. On a rather theoretical basis, JIT compilation may optimize things based on the actual execution pattern and could produce a better (faster) sequence of native opcodes than AOT; in practice, this effect tends to be nullified by the constraints under which JIT compilation must operate (in particular, since JIT occurs when the application is being used and the user is waiting, the JIT compilation must be fast).
In all of the above, the security properties of the Java VM are maintained: all array accesses are still checked, all method calls are verified to happen only on objects that indeed offer the said methods.
If we want to nitpick, then we might argue that ART somewhat reduces security, not because it uses AOT compilation, but because it is new, and new software tends to have more bugs than old software (a large user base represents a lot of testing, so old software has been naturally tested thoroughly). Conversely, we might pretend that AOT compilation is simpler to implement than JIT compilation (because AOT does not have to deal with translating a live application and already allocated objects) and therefore an AOT-based JVM implementation would be less likely to have bugs than a JIT-based JVM. But these considerations are just idle speculation under the usual assumption of "all other things being equal", and it is known that all other things are never equal.