The performance issues alone with the CSV approach is enough to make it a bad idea, and that's before you even get in to the other implications such as future expansion and changes. It's just a bad idea, good, normalized database tables are always best.
There's a lot more debate out this in scholarly settings than you're letting on (or are possibly even aware of). Denormalization is a very common, well-accepted practice. If you're going to insist that it's not acceptable, you need to justify the position.
Please explain why it is always inefficient to store comma-delimited data in an table column. Take various access patterns into account.
For instance, I would argue that storing colors as a comma-delimited string lowers the complexity of accessing a produce from O((M/N)Log(M)Log(N)) to (Log(M)) where N is the total number of color assignments used (relationships between a color and a product) and M is the number of products in the products table.
Log(N) is the cost of the product lookup, assuming a BTREE index.
Log(M) is the cost of the color lookup, assuming a BTREE index.
M/N is the average cost of joining the product to its colors.
So, by denormalizing the data, you're looking at saving a M/N Log(N) lookups, each of which will be a higher cost than the single Log(M) lookup needed for the denormalized form. The cost is the inability to efficiently search, update, or remove single colors globally across all product rows. Of course, making those processes efficient requires yet another table, which introduces another lookup ...
So, if you don't need to do global color updates on a regular basis or search for products by single colors, it's probably more efficient and sensible to store them in a single field. For this application, I'm assuming the ability to do these things needs to be present, making this approach incorrect--but you cannot generalize and say that this a universally incorrect approach. That is not only incorrect, but irresponsibly mis-informative!!!
... forgive the hasty complexity estimates here. In a rush ...