Minor updates are usually bug fixes and security updates, so they should always be applied. This is especially a concern with any Java VMs that communicate with the outside world (web services and clients). Major updates (1.5 to 1.6, 1.6 to 1.7) are generally backward-compatible with earlier versions. This is something that Java has been really reliable for since its inception.
Forward-compatibility is usually the main concern, and the applications or platforms (e.g., Eclipse, Tomcat) that depend on new Java features (e.g., Java 5 generics, Java 6 annotations, Java 8 lambda expressions) will generally drive the decision for major platform upgrades in our shop. As one example, you may find Java 6 clients suddenly unable to access some HTTPS web sites since the last few months due to response to the logjam SSL vulnerability, which has prompted many web administrators to upgrade their SSL certificates to 2048 bit keys, a key size that Java 6 does not support, but one that Java 7 and 8 do support.
In the past, there has generally been a window of three to five years where two or three different major Java versions are in general use, until some critical feature such as those listed above prompts a shift toward a newer version.
Our development environment is still targeting Java 6 where needed (for older OS X clients), Java 7 for new development, and Java 8 for our server environment. Basically, we want a stable production environment based on Java 8 before we start relying on Java 8 features in our development environment. The backward compatibility of Java gives us a long time to make this transition.
For Java 6, I believe the lack of 1024DH support is the nail in the coffin.