First of all, thank you 
dostovel for putting me on this course. It is exactly what I was looking for.
Quick question on the organization though... I don't know if the earlier versions of Blender didn't work with collections? Is that why the layers? If it was my project nowadays I would do the same level of organizing but probably using a master collection for the Feathers, then subcollections inside for each type of feathers. Is that what the updated version of what Kent does here would be?
And a second question: when duplicating, we could have chosen to share the object data so only one of them would need tweaking later if we had to (mind that I haven't watched the texturing and UV portion yet, so that might have not made sense anyway). But the question is: on a computing efficiency level, is it better to make duplicates or linked duplicates?
You are right, early Blender didn't have collections, it had those little squares or layers on the bottom and those were all the "collections" you had to work with. As you say, you can organize the feathers nowadays in that way you describe or any other way you feel would work best, there's no right or wrong. I bet you appreciate collections now more than ever. You always ended up using all the layers and you're like dangs it, I need more squares.
And yes, on computer efficiency, it is absolutely much better to have linked duplicates, as long as it is a possibility, since of course if you need variation you can't achieve that with links duplicates. But for something that has a lot of repetitiveness, you can get away with a couple of unique objects and distribute them in a way where the repetitiveness is hidden.
Hi Nathi,
You are right, blender didn't have Collections before 2.8. Layers were what we used, we were limited to 20 Layers that couldn't be nested and by default you couldn't even name them. Collections and sub-Collections are indeed how we organize this now.
And yes, linked duplicates are more efficient, because they use less Memory. Mind you, it doesn't make a difference on the actual Render time.
And you can have different Materials and different UV Maps for Linked Duplicates (using more Memory than with one Material and UV Map, but less than not-Linked Duplicates):
Nice! Thank you guys for clarifying it.
Very interesting that it would be more computing efficient but not affect render times, I would have not guessed that.
And thanks for the example with the UV Maps, that will definitely come in handy.
When it comes to linked duplicates and rendering it depends on the situation and your hardware. In some cases the amount of time saved on rendering is too small. If you're using an acient system like mine.(barely meets the minimum requirements for 2.X and is technically below the min specs for 3.x and won't work with 4.2. I only have 2 cores on my AMD Athelon II.) You WILL notice shorter render times. We're talking fractions of a second, but they add up when rendering an animation. It also depends on poly count and texture processing(Larger images or more nodes on a procedural texture) vs the number of link duplicates. So, technically it does save render times, but is it enough to make a noticable difference to make it worth it.