to be honest, i haven’t tested the overhead of objects vs structs myself, but i have heard from many sources, including Rama, that structs are cheaper to use than uobjects, and i assume he did the research. also, i have looked at the code of many games, including many game boy rpgs, and they use structs for holding data, and i assume game boy games are about as optimized for performance as you will find. also i have read lots of articles on data oriented design vs object oriented design, and they say that oop has performance drawbacks. although it does have better security and better encapsulation.
OOP is great, but if you get too grainular with how much you split up your objects, you end up with alot of tiny parts that depend on each other, and alot of overhead for creating and destroying small objects, which is bad for performance and hard to read. im not saying throw out Object Oriented programming, just that smaller objects can sometimes be refactored into larger objects to improve performance, and whenever possible, use structs instead of objects, when working with state data.
when you say an inventory and a quest manager should be separate things, it makes me think you are more worried about aesthetics than performance. functionally, they do the same thing: they are both just interfaces that wrap an array. they both just add items and check on items.
why do you need more than one interface for getting/setting elements in an array? why should these be separate objects? if you claim its because the “single responsibility principle”, i would point out that my inventory does have a single responsibility: keeping track of data arrays.
i would also point out that removing the quest responsibilities from the inventory, does not make the inventory any simpler. it will still need to add items and check on items, but now you have another object that also needs to add and check on items. and you need both of those objects to work with your save game system.