Well, first, we should define “functional programming”:
It stands to reason that there would be certain penalties for holding really close to the functional paradigm, because avoidance of state and mutable structures implies a lot of object re-creation.
However, you should not worry yourself with performance until it actually becomes a problem.
The functional paradigm has design advantages for which many (including myself) would happily trade CPU cycles.
About OOP in general: The key is to create objects which represent well defined roles in your “high-level” vision of the system. Also, these objects should be fairly independent of each-other (you can change one without having to make significant changes to the other), therefore preserving some semblance of modularity, and, more importantly -> sanity (in the long term).
In short, it’s an organizational methodology, in which poor performance still depends on the details of implementation, rather than some intrinsic quality of the general approach.
Object Oriented Programming serves Data Modeling purposes better, you can wrap common properties and actions of an “Entity” and make it a class. Then this piece of code will be better maintainable and reusable.