In the latest LTS those all can still be enabled, so while it is a serious problem when they are finally removed, for now it's not really a good reason to block an upgrade.
I think that's fair. Yes, there is an escape hatch currently available. But what is hard is knowing if your application is relying on any internal/private behavior that it shouldn't. Since the dependency hierarchy of most Java projects is very deep, it's hard to know if any dependencies of A -> B -> C -> D are going to call into restricted areas. You might not even know you have a problem until runtime, because you've --add-exports everything and now you have a stacktrace to try and deal with in production.
But yes, maybe not a good reason to completely block an upgrade. It's just postponing the pain, though.
Custom libraries have, unfortunately over the years, picked up the bad habits (by forking/following public libraries) relying on reflection and packages that shouldn't be directly used (sun.* packages, etc.). So companies are wedged in because they made the poor decision to rely on private packages. And now, Java 11+ enforces this by default.
There are open source Java libraries today that don't run unless you "add-exports" to basically everything. google-java-format comes to mind, because it's using an internal java code parser from the JDK, for example.