Yes, this will cause some issues initially but I have hunk it's a good move for Java in the long term.
A lot more software is broken by Jigsaw than would've been broken if s.m.U went away. Plus: there's an escape hatch: for better or worse, if s.m.U went away, you'd start seeing a whole ton more JNI.
For instance, Leinigen putting itself on the boot classpath to get faster startup time is really a hack to work around the problem that Clojure apps do way too much stuff at startup and generates very old bytecode forms that takes a lot of work to verify. If you want to disable bytecode verification for Clojure apps you could just use -verify:none instead of blaming Java 9 for changing the way things are loaded at startup, which has never been a guaranteed property of the platform.
Lots of complex apps and language runtimes have been making assumptions about things that were never guaranteed or even documented and will need adjustment in Java 9, but that's OK - the prior situation was never sustainable and a big part of why Java 9 is taking so long and is such a big effort is to get the ecosystem onto a more sustainable, supported footing. Creating supported replacements for Unsafe stuff is one such example but there are plenty of others.
A lot of the "missing features" seem like things that indicate design smells when used and that I would have looked forward to get rid of.
Maybe there are projects that have compelling use-cases for circular dependencies, heavy use of reflection or classpath introspection but those features impose a substantial cost on the language with relatively little returns. Why can't they be opt-in?