Your question is based on many flawed assumptions. Let me attempt to clear them up:
You said "JVM (Dalvik VM)". That's like saying "Airplane (Bicycle)". These two things have absolutely nothing to do with one another.
You said "...which is basically a virtual processor". Simply false. It is not the case that, every time the words "Virtual Machine" or acronym "VM" is used in a technical context, that it is essentially equivalent to VMware Workstation. This is because products like VMware do in fact emulate an entire computer, not only the CPU, and are running an operating system on top of another operating system. Dalvik VM does not work like that. Not even close.
Java is just a programming language. It's syntax. Android/Dalvik programs happen to use the same or very similar syntax to a completely unrelated desktop/server programming language called Java, which runs on a Java Virtual Machine. In theory, you could write Java code that is very nearly the same speed as C code, since they are both high level programming languages. The devil's in the details of the implementation of the library calls and the way that the runtime is designed, which has very little to do with the syntax of the language.
It is an over-generalization to say that Dalvik VM, the Sun Java Hotspot JVM, or the Java programming language syntax is responsible for high power consumption. The reason is that you have to compare whatever you're talking about to the performance of something else. In the most general case, when you're just comparing the "best-case" capabilities of both platforms, it is in principle possible to make Dalvik apps that are just as fast, or faster, than programs on any other platform. Other than automatic memory management and JIT compilation -- features which are standard in almost all programming environments these days, including on iOS and in JavaScript / HTML5 -- there is very little that separates Dalvik from Objective-C, .NET, Ruby, the Oracle Hotspot JVM, Python, and so on.
The perception that "Java is slow" is due to a problem with old versions of Java, in that they either did not have a Just-In-Time Compiler (JIT), or the JIT they had was very limited in functionality. The JVM has had a Just-In Time Compiler for a very long time now. A JIT compiler is a part of the runtime (for instance, the JVM) that takes processor-independent bytecode -- for example Java bytecode -- and compiles it into native instructions for the CPU. This process is done when the Java program launches, and advanced JIT compilers can optimize individual functions or instructions at runtime to improve their performance based on observed results. For instance, if a method returns true every single time it's called, but it isn't obvious from the original bytecode that it would do so, the JIT compiler can recognize that it just returns true, and replace the function call with a hard-coded value of "true". This is just one example.
JIT compilation and runtime dynamic code analysis techniques have been making huge advances in recent years. Many in the computer science community believe that, in another decade or two, the sophisticated analysis available in dynamically interpreted/compiled languages, such as Java, C# and Ruby, will be so advanced that, in most cases, these languages will execute faster at runtime than statically-compiled languages like C and C++. That's because static compilers are usually limited to compiling code at build-time, and the code is not modified at runtime. But in a runtime environment where the code of the program can re-write itself during execution to perform more efficiently, there is an enormous amount of upside that can be achieved by analyzing the performance of the code and making adjustments to reduce the complexity of the code or the number of instructions that are run on the CPU. For frequently-called code, the time investment required to perform the analysis is far outweighed by the performance benefits of repeatedly calling faster code.
It should be noted that the Android Dalvik VM also contains a JIT, and that it does not use the same bytecode format as the Sun/Oracle JVM. Dalvik's JIT is optimized for low memory environments, and it is very advanced as far as runtime performance enhancements. So it is somewhat of a coincidence that the JVM and Dalvik implement similar optimizations for their respective Java-based runtime environment, but under the hood they are quite different.
Don't forget that Dalvik itself; the Linux kernel; low-level system processes; and the core of Android web browsers (both Firefox and Chrome) are written in native C/C++, and so they do not have any of the overhead concerns that a Dalvik program would. This is the same as iOS. If you're talking about pure Android and not the carrier/third-party bloat that sits on top of it, a very large proportion of what comprises core Android is not written using Dalvik.
Application developers on Android can also, at their option, write native code, bypassing Dalvik. If an application developer felt that Dalvik was acting as a bottleneck in the performance of their code, or causing it to drain too much battery, they could simply write C/C++ or even assembly code if they chose to, without having to obtain Google's approval to do so, and distribute their app like that.
Here are some actual reasons why an Android battery-powered device, or any device, may have problems with battery life:
Applications that keep the CPU, screen, or data connection awake. In particular, 4G chipsets such as LTE use a great deal of energy when they are powered on, so if you have background programs that continually wake up the LTE chip to transfer a few kilobytes of data, that will drain your battery very fast. The screen on modern smartphones and tablets is also very energy-intensive, unless you turn the brightness down to minimal.
"Bloatware" that is required to be on the device, and can't be uninstalled. Some unscrupulous carriers require you to run bloatware that takes up CPU cycles and keeps the data connection awake. This can be either due to incompetence on the part of the software developers of the bloatware, or an intentional goal of monitoring your activities on your smartphone and sending them to a remote server for data mining, which is very energy-intensive for your battery.
Finally, I disagree with your assessment that Android has worse battery life problems than on other mobile platforms. Certain phones and devices may indeed have battery life problems, either due to the capacity of the battery relative to the energy consumption of the hardware; poorly optimized power settings (elected by the user, the carrier, or the manufacturer); or bloatware apps that keep chips in the phone awake all the time. But for every example of a device that has battery problems, I can give you a counterexample of a device with excellent battery life. There's no simple way to generalize that "it's Dalvik" or "it's Linux" or "it's Java". Power optimization is a complicated hardware/software mish-mosh of competing concerns, including performance, responsiveness, and the user expectations for battery life, with pros and cons to each choice. To fully understand the power profile of a device, you have to take a close look at the battery itself, all of the hardware, and all of the software running on the device.