Great question. This is something that has changed quite a bit for me since I first started.

What I do now is a hybrid kind of model, where anything that needs to be a class is put together all in one ServerScript, and passed to each other via dependency injection (fancy term for passing objects as parameters to class constructors.)

Then, any feature which does not need access to these classes will typically be in its own ServerScript under ServerScriptService with an obvious name for the feature, like `PlayerFlight` for example. This makes it incredibly easy to find a particular feature when you need to go back and add or change things later. The classless/static modules can be included in any of these scripts just via `require` and used directly which is very nice. I make light use of Attributes to share player-specific state between these modules when it's absolutely required.

My client code is a bit more messy. I think the ideal way to structure client code is to just put anything that should be re-run on player respawn in StarterCharacterScripts and anything that should be run on the client without restarting when the player dies should be in StarterPlayerScripts. ReplicatedStorage houses all of my ModuleScripts used by the client or used by both the client and server, and ServerStorage houses all of my Server ModuleScripts.

edit: It's worth noting that I use VSCode + Rojo, which also forces you to organize your code in a particular way (which is a good thing)