I'll preface this by saying that every situation is different so it's hard to say what the "best" option is. This tutorial seems to go the route of having different product variation types, with a specific color attribute created per variation type. Having a separate variation type for every item feels a bit awkward, but it might make sense in your scenario.
Two other solutions that I can think of are:
1. Multiple Attributes (only):
You could do this without creating unique product types for every product, or even multiple product variation types. You could have 5, 10, 2000, however many different color attributes, all of which are made available to your single product variation type.
The main drawback that I foresee with having separate attributes for each color set is that, after the fact, any grouping/reporting that needs to be done on colors may need to accommodate all of these disparate attributes in a single place. One way to help mitigate this might be to create an "attribute categories" (or similar) taxonomy vocabulary to group related attributes together, and tag that on a taxonomy ref field on each attribute. If you anticipate this only ever being an issue for "colors" then you could probably also get away with adding a boolean field to do something similar.
That said, having the color sets as separate attributes might be preferred for reporting as well. Hard to say.
2. One Attribute
Another option is to have a single Color attribute containing every single color, but add a Product Entity Reference field onto it. In this case, every color would inherently be treated the same, but you could relate them directly to their associated Products. This avoids the issue of needing to relate the different attributes after the fact. This would give you the option to do a form_alter on the product_variation creation form to limit the options on the color attribute field to those which reference the Product that you're creating a variation of.
This option could end up with a pretty big list of options when editing the attribute, though, so it might be worth populating it with a bunch of dummy data to see how it fares. Devel_generate (included with Devel module) might be helpful, here.
EDIT: I should note that I initially failed to say that option 2 was my preferred option, for the same reason that Ryan notes in his answer. That is to say, all colors are colors and should be present on the same attribute. If Select2 is viable for attributes fields then that's probably the simplest way to make the list more manageable when authoring new product variations.
Alternatively, as mentioned in 2, using a reference field on each color to its related products (or alternatively a reference field on the product to its given colors) would maintain the "correct" single attribute while also allowing you to limit the options to those appropriate for the current product. IMO this probably leads to a less overwhelming interface in the event that the list of available colors is sufficiently large, and could also be paired with something like Select2 to further improve the authoring UI/UX.
