In an imperative OOP language, an object can indeed be seen as a glorified dynamic data structure with its fields specification distributed between object ancestors (in the case of a class-based language, the ancestors being the class and its superclasses).
Not clear when do you mean by “object state”. Logtalk is a declarative OOP language (Declarative object-oriented programming — The Logtalk Handbook v3.72.0 documentation). An object represents a theory (defined by a set of predicate declarations and definitions) and a hierarchy provides for theory extension. Mutable state, if that’s what you’re thinking about, is as an alien notion as it is in Prolog. Sure, you can use dynamic predicates, in the same way you can use them in plain Prolog or Prolog modules, to have non-backtracable state. But backtracable state means using logical variables as in predicates arguments (and object parameters).
Getting back on topic, when integrating Prolog with traditional, imperative OOP languages, Logtalk can work as a bridge by providing useful abstractions (see e.g. https://github.com/LogtalkDotOrg/logtalk3/tree/master/examples/document_converter) but, by itself, cannot solve the fundamental mismatch between declarative and imperative semantics. The good news is that we often don’t need to worry about mixed metaphors as separation of concerns can allow both sides to cooperate nicely.