It used to bother me as well. For me it was the perception that “Actors” have a position, occupy space, and are ticked but this is not always true. The PlayerController and Any AInfo Object do not really do this; yes they have a position, but they exist only to facilitate some greater functionality. My AItems when attached to the character do not technically move as the attachment sets their relative position to that of the Pawn by default, I have also disabled their ability to Tick (at least when they are in my inventory). But this may not be enough; to save on bandwidth for replication and memory I also utilize an Item stacking system for most items so if you are carrying 20 berries, you are actually only carrying 1 berry Actor with a stack count of 20, so that cuts down the Actor replication Cost. However Weapons and Armor are all “unique” so… no stacking there, but I do also utilize a limited inventory slot system (though it does have an unlimited mode).
I originally was looking to do something like that for the ItemActor with UObjects (To make life easier) but for me my Items have always had a need to be very dynamic, each one doing something completely different and requiring functionality configuration via Blueprints for when the item is used by the player. For instance a Consumable item needs to apply it’s effects, a Weapon or Armor needs to equip to the proper equipment slot and may also apply effects to the player (such as setting enemies who hit them ablaze). Granted you could specify all that functionality in the ItemActor and keep the type of class you need to spawn in order to apply those effects so that when the player “uses” the item you spawn an actor, apply the effects, and then destroy it after it is done. For this method I worry about thrashing memory though, but Epic may have build a more efficient memory allocator with their Garbage Collector. As it is my current method of Spawning an new item for pickup and drop bothers me, but I was told if I want to switch on and off replicating only to owners that is how I needed to do it from an Epic staff member… It did actually end up working faster replication wise in the end… much faster…