Fundamentally, objects which communicate to each other via interfaces is the only structure or guiding rails that OOP gives you. Encoded in that statement is the value of "encapsulation" or modularization, but also buried in there is the cost of dealing with decentralized state up-front.

Why? Because if you have the "interesting" kind of Objects that OO prescribes, then you have a portion of your app state inside. If you have a few objects, then you immediately have a problem of decentralized state. Right away you must come up with a strategy.

As a side note, OOP is not about classes, factories, singletons, etc., but a good OOP language should support many of these things, because classes are about easily making objects, often with abbreviated notation. Since objects are just arbitrarily nestable key-value data structures, if your language supports functions, I don't see why you couldn't manually rebuild that whole world of OO machinery.

FP offers you even less guidance on how you should structure your code. Is your state centralized? Decentralized? FP has no prescription. Beyond the function, how should you modularize your code? FP has no prescription. FP is a loose collection of values, stemming from the function as the fundamental unit of code reuse and manipulation; with that is the implicit value of immutability, because immutability + functions means repeatable determinism, a nice trait for anyone looking to make stable systems.