Like I've gone on extensive infodumps to my partner about how monads, higher kinded types, and the IO monad work and how fucking cool they are, but like, fuck off, this is not the one true paradigm because there IS no one true paradigm. I'm an anarchist, and that applies to my methodological approach to software too: I don't think there is one true correct way to do everything that's always better in all situations, some ultimate paradigm od plan, whether IRL or in programming, because that's a fucking spook, I think that the right answer for any situation is highly contextual and embedded in the particularity of that situation and is best decided by the people directly involved in the moment in light of both the specific context and the wider context and systems at work.
So sometimes modeling the problem as structs (or components) that encapsulate some state and some behavior and change over time just describes things more naturally. Not all the time, and inheritance is horrible and we should use composition and interfaces instead, but most of the time that's a much more natural paradigm for modeling certain kinds of things. And sometimes it's best to use pure functional paradigms. And sometimes it's best to use entity component systems. Sometimes an imperative loop is what you want, and sometimes (probably most times), map, foldl, etc are what you want.
Ultimately, the way I program, I tend to write out all the code to do what I want directly, and then I look carefully and find all the duplicated code and code structures and then use *whatever* abstractions will most naturally factor out the duplication into a conceptually clean abstraction that mirrors just exactly what was actually necessary and repeated, with just enough future flexibility to not lock you in. And I think that's much better than starting out with some specific set of abstractions you want to use, and, like someone with a hammer thinking everything is a nail, trying to force that one set of abstractions on everything. Or trying to start with abstractions first, and build the best most extensible abstraction for something possible without knowing in advance what the actual use cases practically speaking will be. That's not clever, that's very silly and rigid.