If you have a project that includes JAR files and AAR files as dependencies (see note below), then you can have Android-specific JARs as dependencies that rely on classes in the Android APIs, though the JAR files can't contain Android resources as you already know. Just because it depends on Android classes doesn't mean it needs to be packaged as an AAR.
Here I'm talking about what's perhaps a single-module project that includes a number of JAR and AAR dependencies. A JAR file is just a collection of class files (and perhaps non-Android resources and other files) and doesn't have a sense of dependencies, so there's nothing to break. When it comes time to do the build, the builder just bundles everything together and packages it and doesn't check to see if the JAR has unresolvable dependencies on other classes -- you'll find out with classloader exceptions at runtime.
If you're talking about library modules in a multimodule project in the IDE, then that's a different matter. If you have a module A which can compile to a plain JAR (it uses the apply plugin: 'java' statement in the build file), then it can't depend on an Android module (apply plugin: 'android-library') which compiles to an AAR. This will likely never be fixed, or at least not in the foreseeable future: it's because Android modules have a much more complex notion of source folders, and the Java plugin in Gradle can't understand Android's source sets.
The converse is true, though -- Android modules can depend on plain Java modules.
NOTE
Due to limitations not yet resolved in the Gradle builder, you can't access local AARs in the same way you do as JARs in your build files (by referencing them via compile files(...) statements); you have to fool Gradle into thinking they're in some sort of Maven repository (perhaps by putting them in an actual Maven repository, which can be local). See Adding local .aar files to my gradle build for a workaround if you need it.
