It is easy to find reasons to use a new version of Java. Normally if you have the option, the more modern java syntax should be used instead of legacy code. But there are restrictions – some reasons you may be bound by an older version is:
The new version is too new. Your organization may have a reasonable policy against immediate adoption for security or risk mitigation. (If you're working on your own in your garage, this problem doesn't occur).
The build server or the target application server will not run code built under the latest compiler. For example, if your Tomcat uses Java 7, Java 8 binaries won't run on it.
Some of the operating systems the application may run on do not have a released version of the new Java. It may be a year before your target platform is ported properly.
The code needs to run as an applet or webstart application – many browsers will not have been upgraded from early versions of Java, despite security flaws. (Applets are dead anyhow now that HTML5 is here; you shouldn't use applets).
The code will communicate using raw RMI or serialization to older versions of Java.
The code will be released as a library where the library may be desired for projects that have an older java version restriction.
There are too many lines of code affected by deprecated functions, which would need to be fixed before usual development can continue.
Most projects do not fit the above criteria, so all improved Java language constructs should generally be embraced. There tends to be few radical changes between Java version so the upgrade path should be painless and not likely to cause confusion. It may translate into better productivity.
