With major releases gone, this isn't hard, and, overall cheaper and easier than upgrading less frequently. But it is some work, which is why the LTS service was added for the benefit of legacy applications. Note that under the old model, LTS didn't exist. There was a new feature release every six months that everyone had to upgrade to. The names of those releases didn't stand out as much (8u20, 8u40 for feature releases [1] as opposed to, say, 8u25, 8u45 for patches) as they do now when we did away with major releases and gave every new feature release a new integer number.
Because now the feature releases can add new APIs rather than just new JVM features as they did under the old model, this process can be slightly more work, but still significantly less work over time. As regularly maintained applications update code and dependencies regularly, anyway, this is a clear win. Not only is the upgrade process easier and cheaper, but you get to enjoy the regular and significant performance improvements that have always been part of the six-monthly feature releases, but aren't in the LTS patches.
[1]: Those feature releases under the old model also added major new features with significant changes to the VM. For example, the G1 GC and JFR were added in feature releases.
Because now the feature releases can add new APIs rather than just new JVM features as they did under the old model, this process can be slightly more work, but still significantly less work over time. As regularly maintained applications update code and dependencies regularly, anyway, this is a clear win. Not only is the upgrade process easier and cheaper, but you get to enjoy the regular and significant performance improvements that have always been part of the six-monthly feature releases, but aren't in the LTS patches.
[1]: Those feature releases under the old model also added major new features with significant changes to the VM. For example, the G1 GC and JFR were added in feature releases.