Treat single player as a local multiplayer if this is really a concern. Just use the loopback address. That’s what I do.
90% of apps states is for visuals. You drag along a ton of stupid shit just to execute something once a frame. Moreover, that code will never be usable anywhere else outside of a JME application.
It makes more sense to go the other way, adapt systems to states. AppStates are kind of a broken design. They are supposed to let you ‘extend through composition’ a JME application but then they don’t even fully support that. (Just like Controls are only a partial solution for Spatials.) GameSystems are way simpler because their only job is to execute game code and hook you up with other systems. No weird update delay, no preRender, postNosePick, postRender, preUpdate, postUpdate, stateAttached, stateDetached garbage.
So I guess it’s the examples you are criticizing? They may have lost something in trying to be simple. As I develop the moss stuff I’m trying to be more modular and clearly spell out client, server, and common… but in the end I think that only makes your problem worse maybe.
This code will always be far and away from a giant Main.java class. We can probably argue over the decomposition but there will always be some kind of decomposition.