The crux of the matter you stated as '..to avoid unnecessary duplication'.
Let your conceptual requirements dictate this and not your ideas of 'let's keep the database schema lean', or ideas of performance or something similar.
To take your own example from your comment. If you have different content types that serve the same purpose or that are grouped together somehow (ie all are products types that you group under a menu product catalog) and each product's type has a cover image that you want to show when you navigate to that product type listing, then re-using the cover image for each product type makes sense because it is conceptually similar.
On the contrary, re-using a product type cover image for a user image field would not make sense as it is conceptually unrelated, even though it might have the exact same database schema.
Not being able to re-use a field on the same content type makes sense from a conceptual point of view also. To have multiple fields all you need to do is set the multiplicity on the field, whether the field is 'simple', a field collection, or an entity reference. This already enforces a conceptual similarity.
Always design to your conceptual requirements first. This allows for:
better understanding of the design.
being able to easier adapt to changing future requirements
cleaner custom sql queries against the field's database if need be.