Some people might call it nano optimization. The thing is that we aren't talking about meshes with 2kk vertices with tangent/normal/position/color/whatever information in Vector3s (this class overhead, which is not only the reference, scales fast in memory alone). Is it worth to talk about this or the properties with getters and setters? Probably not in our context.
Can interfaces lead to copy/paste code? Yes, that's also true. I would go with ECS if the system can go out of hands, and that means to have a bunch of function calls, searches, and overheady stuff. At the end, it depends on the system.

if you create a missile projectile and need to add the components "RocketMovement", "RocketExplode", "RocketHoming", etc - you end up with a large amount of 64 bit references linking these together.

Those '64 bit references' are presumably the same size as the function pointers in the vtable if you had a list of Missiles and needed to call virtual RocketXYZ functions on some of them. This isn't a valid concern unless you have thousands of these all existing at the same time and not many virtual functions by comparison. If you're 'rather new to game development' like you say then I humbly submit that you are mistaken in your concern here.

I don't necessarily have a problem with inheritance in this context - e.g. I would argue that a Shield and a Weapon are interchangeable for many purposes (they can be picked up, held in a hand, carried in inventory, dropped on the floor, bought and sold) but if you ever want to use a shield as a weapon (e.g. a shield bash attack) or want to combine other traits (e.g. is a wizard's staff a weapon or a wand-like magical artifact?) you often find yourself pulled back towards a single Item class with flags, properties and components defining how they operate.

if you create a missile projectile and need to add the components "RocketMovement", "RocketExplode", "RocketHoming", etc - you end up with a large amount of 64 bit references linking these together.

Those '64 bit references' are presumably the same size as the function pointers in the vtable if you had a list of Missiles and needed to call virtual RocketXYZ functions on some of them. This isn't a valid concern unless you have thousands of these all existing at the same time and not many virtual functions by comparison. If you're 'rather new to game development' like you say then I humbly submit that you are mistaken in your concern here.

I don't necessarily have a problem with inheritance in this context - e.g. I would argue that a Shield and a Weapon are interchangeable for many purposes (they can be picked up, held in a hand, carried in inventory, dropped on the floor, bought and sold) but if you ever want to use a shield as a weapon (e.g. a shield bash attack) or want to combine other traits (e.g. is a wizard's staff a weapon or a wand-like magical artifact?) you often find yourself pulled back towards a single Item class with flags, properties and components defining how they operate.

The vtable saves a funciton pointer for each virtual method per class (each instance has one vtable pointer pointing to the same table), attaching three components rather than having one type id increases the memory overhead per instance from 32 to 384 bits (assuming they are doubly linked). However, if you say it is of no concern, i will trust your judgement on this.

Sure, it's per class, but it's for every virtual method in that class and every class it inherits from, and it costs you an extra level of indirection each time, and the inability to store these objects contiguously. It's usually irrelevant. But if we're comparing it to having a small amount of extra pointer data in each object (the very existence of which implies a bunch of extra data that would dwarf the size of that pointer anyway, making the '32 to 384' comparison meaningless) then we're deep in micro-optimisation territory which shouldn't be considered until you know you have a performance issue. (Or intend to launch on a Raspberry Pi or the like.)

(e.g. The rocket example - typically your rocket position, velocity, and orientation are going to cost you almost 150 bytes between them, before you add on any behaviour or presentation properties at all, and you're worried about 24 bytes for 3 pointers?)

Hmm, when i calculate it, i get 40 bytes (12 per vector, 16 for a quaternion using 4 floats - assuming they are all structs). But i guess you're right. The reason i mentioned this is because i once asked a similar question (regarding block storage in a block builder game) and was told that even having a single reference to the block type was wasteful compared to having a type identifier int. Overall though i think you gain a lot more from having a system which is flexible and easy to understand.