I'm not questioning the need for software to be reliable. What I mean is that it's "usually" (in practice) a useful thing for the people using Hibernate to be able to pick a relaxed isolation level for some entities even when they need to set a stronger setting on the connection, since the connection settings are global and will affect all operations.

This is in fact very common: people want to cache some reference data very aggressively, e.g. make sure some specific items are read from the actual database during maintenance events or manual triggers - for example that's why there "manual" eviction APIs.
Still in a real world application while some data (entity types) are fine to be treated with a relaxed isolation level, you might have other entities which need strong reliability.

The alternative to such flexibility being that people can't always afford the performance overhead of having (unnecessarily) the whole model treated at the same level and will compromise by setting the isolation level to a more relaxed setting. So the end result is that all use cases will be treated equally bad, severely hurting our "sense of software reliability" ...

I don't disagree at all on having options to have the cache to behave close to serializable. That's an amazing feat of engineering; just saying there needs to be more flexibility than coupling cache modes to isolation levels and I wouldn't relate them at all.

The default is sane already: no 2LC caching enabled! Can't be safer than that, anything else is a performance / reliability compromise and that belongs in the realm of expert tuning.

And sure 2LC must be transparent to other operations but such tuning is a (behind the scenes) explicit compromise trading reliability for performance on specifically selected operations. An important point for the "transparency" is that one should be able to tune such options without re-compiling the application but ovsiouly one can't expect it to behave entirely the same.. it's hopefully at very least going to be faster