It's different because from 8u20 to 8u40 we had the expectation of only getting very minor bug fixes and security patches which are very unlikely to break anything for us

Then your expectations were very wrong. Before, as now, every six months Java had feature releases with big changes. For example, 7u4 made the G1 garbage collector production-ready, 7u6 saw the inclusion of the JavaFX SDK and added support for Linux on Arm, 7u40 introduced Java Flight Recorder and Mission Control, and 8u40 introduced AppCDS. These were big changes that touched and changed many aspects of the JVM.

From 11 to 16 there's been quite a few major undertakings

Not only has that always been the case with feature releases, you'd be wrong to believe patches don't contain them. I'm not only talking about things like the backport of JFR and Shenandoah, but the biggest code-breaking change in the entire 9-16 time frame happened to be in a patch release (11.0.2, and 8u202).

My point is that those expectations are governed by the psychology of version names rather than by actual reality.

the assumption that the latest is the safest has been shown to be false more than once

I agree with that general sentiment, but things that broke with Java happened for the opposite reason: dependencies that were undependable and ill-maintained all along, and that simply exposed their problems due to the upgrade. Very few significant spec changes were made since 8, and libraries broke because they hacked JDK internals and accumulated technical debt and security problems over the years. Hopefully, when the module system's encapsulation is finally turned on in 16, we can start the process of cleaning up the ecosystem.

But again: we can't convince all our customers that they need to accept things are different now: we need to give them what they want

I'm sorry, but you have no choice. It's either that or lying to them. There are two new upgrade paths now: the default path and the LTS path. Of the two, the default path is more similar to how things used to be: a feature release every six months, with the vast majority of the JDK developers supporting and maintaining the current feature release (no one stayed behind to support 8u20 when 8u40 came out). LTS is quite different, and something we've never had before. Small teams stay behind and backport stuff from mainline. The quality of the work varies widely by vendor, and we've already had at least one case of a regression in an 11 patch due to a bad backport.

It's perfectly fine to choose LTS if that's what's right for you, but I have a feeling your choice of LTS is based on what you've convinced yourself it is rather than what it actually is. An LTS (a real one, i.e. paid, not the "free LTS" Updates builds that contain just backports and are only partially maintained) is an excellent choice for applications that aren't heavily maintained anymore. For applications that are still heavily developed and maintained, the current version is a simply more responsible choice.