Many organizations are stuck on Java 8 because Java 9 made breaking changes. (Java 11 also made breaking changes.) Many of these changes also broke some popular libraries at the time that hacked into the JDK internals, so it meant a significant refactor for software that might be in maintenance mode already.
To clarify Java made changes to things they never promised would be a part of backward compatibility. Libraries were using things from JDK internals/implementation details, things that were never guaranteed to be there.
It isn't that severe of a break. Most of the friction was with the libraries with transitive dependencies, like ASM, that depend on a particular bytecode version, using internal classes that were removed (e.g. sun.misc.BASE64Encoder), or the new module system encapsulating APIs that were intended to be internal-only (usually fixable with JVM runtime flags.)
A lot of organizations that use Java are very conservative with their tech changes, and didn't see a compelling reason to upgrade. This was especially true since Android Java still used Java 8, so many popular libraries continued to support Java 8 for their Android userbase.
Java's version history crawled along at a snail's pace until Java 10, when they switched from a feature-based to a time-based release schedule. The release cycle has been pretty quick after that, since that happened only after 2017 or so.
That, combined with some pretty large changes in the underlying security model, mean that a lot of places have been stuck on Java 8 for a real long time. It's much harder to move from Java 8 to Java 9/10/11 in a lot of places than it is to then go from 9/10/11 to 17, for multiple overlapping tech debt cleanup reasons.