I'm pretty familliar with .NET and know that patches and upgrades are mutually exclusive to framework versions (1.x) and (2.x / 3.x) and (4.x). This segregation makes it easy to understand the dependencies.
What logic or segregation applies to applying Java upgrades? When should I do it, or when should I not?
As Always the answer is 'It Depends'.
If you are a consumer and the patch is security related do it now.
If you are an enterprise and you are running an application server and the patch details do not mention a security vulnerability that you are likely to hit (User running malicious JNLP application) you can hold off. If the 'patch' is adding new functionality such as Java 1.6.0 Update 10 (Update N) then you can maybe hold off.
In general updates to a certain Java version (1.4.2, 5, 6, 7) should be API stable and ok to update, but depending on what your application does to java you may need to test or hold off.
For instance recently Oracle changed some metadata about the HotSpot VM in a patch which caused the Eclipse IDE to fail.
99 times out of a 100 the Java patches should be API stable and have non-breaking changes.
Many well-known versions of applications that require a specific java version usually include that version of java binaries with their application, and launching it is some variation of <-lots -of -switches>.
In the above case, upgrading the general/system-wide/default java usually has no impact on the application with it's own java binaries. On the other hand, you may also be unaware that the application-specific version of java (with a known vulnerability) exists when you update the system default java, unless you are actually measuring and reporting on it using a software inventory application.
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.
