Марат

Простые запросы проще сопровождать (нежели гроздья WHEN-ов).
По скорости зависит от наличия одновременных запросов к этой же таблице, с точки зрения блокировок - кол-во их будет одинаковое.
www.mysql.ru/docs/man/InnoDB_Locks_set.html и т.д.

P.S. Подвопрос:
ELSE text <--дополнительный вопрос-- это же не обязательно, зачем тогда так делать?
Это во многих SQL серверах так(например, в Oracle) - анализатор не знает значений полей, участвующих в условиях When, потому ветка ELSE хотя и не обязательна, но может возникнуть RUNTIME ошибка при оптимизации запроса для выполнения.

Плюсы использования limit:
1) Ограничение и предсказуемость кол-во результирующих строк со стороны сервера,
2) Меньше нагрузка на сеть,
3) Проще проектировать GUI выдавая результат запроса "пачками" с определенным количеством строк.
4) Подсказка для оптимизатора запросов, что приведет к увеличению производительности выборки со стороны сервера

Минусы использования limit:
1) Можно сломать логику и/или пропустить ошибку. Допустим в таблице справочника отсутствует primary key и задублировалась запись. Применяя выборки с limit 1 - не поймаете данную ошибку.
2) Отсутствует в стандарте SQL до 2011.
3) Не стандартизирован в SQL92. Многие СУБД имеют аналоги (top - MSSQL, Offset - вроде в Postgres; или, еще хуже - конструкции с where rownum = в Oracle ). То есть меняя версию СУБД Вам, возможно, придется переписать все подобного рода запросы.

P.S. Такого рода споры о целесообразности применения конструкций СУБД необходимо решать с 2х точек зрения СУБД и Приложения. Уверены, что у Вас 99.999999% нет ошибок в реализации объектов СУБД и не планируете переходить на другие СУБД - применяйте limit, иначе задумайтесь.
P.S.S. Аналогичен спор и о необходимости Order by. Серверные люди скажут, что order by - баловство, не стоит нагружать сервер задачами сортировки полученных данных - это "крестьянское" дело должно ложиться на плечи приложения :)

По моему все можно :-) ибо
Я бы делал через subquery (удобно для выборок по разным условиям из составленного "набора" пересечений)

select BSproduct from
  ( -- Список продуктов имеющих черный цвет и малый размер
    select product as BSProduct from
      (
        SELECT  t1.id,  t1.name AS product,  t3.name AS color,  t5.name AS size
          FROM  `product` AS t1
          JOIN `product_color` AS t2 ON t1.id = t2.product_id
          JOIN `color` AS t3 ON t2.color_id = t3.id
          JOIN `product_size` AS t4 ON t1.id = t4.product_id
          JOIN `size` AS t5 ON t4.size_id = t5.id
      ) 
    where color = "black" and size = "S"  
  ) as BlackAndSmallSize, 
  ( -- Список продуктов имеющих черный цвет и средний размер
    select product as BMProduct from
      (
        SELECT  t1.id,  t1.name AS product,  t3.name AS color,  t5.name AS size
          FROM  `product` AS t1
          JOIN `product_color` AS t2 ON t1.id = t2.product_id
          JOIN `color` AS t3 ON t2.color_id = t3.id
          JOIN `product_size` AS t4 ON t1.id = t4.product_id
          JOIN `size` AS t5 ON t4.size_id = t5.id
      ) 
    where color = "black" and size = "M"  
  ) as BlackAndMidSize, 
  ( -- Список продуктов имеющих большой размер
    select product as LProduct from
      (
        SELECT  t1.id,  t1.name AS product,  t3.name AS color,  t5.name AS size
          FROM  `product` AS t1
          JOIN `product_color` AS t2 ON t1.id = t2.product_id
          JOIN `color` AS t3 ON t2.color_id = t3.id
          JOIN `product_size` AS t4 ON t1.id = t4.product_id
          JOIN `size` AS t5 ON t4.size_id = t5.id
      ) 
    where size = "L"  
  ) as LargeSize
where BSProduct=BMProduct and BMProduct=LProduct

Не знаю как насчет MySQL и его форков, в некоторых SQL серверах можно заранее задавать подзапросы типа

(
        SELECT  t1.id,  t1.name AS product,  t3.name AS color,  t5.name AS size
          FROM  `product` AS t1
          JOIN `product_color` AS t2 ON t1.id = t2.product_id
          JOIN `color` AS t3 ON t2.color_id = t3.id
          JOIN `product_size` AS t4 ON t1.id = t4.product_id
          JOIN `size` AS t5 ON t4.size_id = t5.id
      )

с помощью команды WITH - тогда объем текста выборки сократится в разы.

Если нужно 2 эти операции делать в связке, то можно закрепить это поведение в самой БД через триггер, который после выполнения UPDATE сам инициирует необходимый INSERT. Логику insert-а (в вопросе уже готовые значения) пропишите в теле триггера (для Update возможен доступ к значениям до выполнения команды через псевдозапись (или как правильно в Maria они называются) OLD, к новым значениям - через псевдозапись NEW.

CREATE TRIGGER `update_users` AFTER UPDATE ON `users`
FOR EACH ROW 
BEGIN
   INSERT INTO payments(status_id, user_id, description, currency_id, 
       amount, bonus_amount, sum) 
    values('2' ,new.id, 'test', 643, 
       old.balance, old.balance+new.balance, new.balance);
END;

тут свои + и -.
+) БД управляет сама поведением записей (на случай, если кто 'забудет' прописать вторую команду или оформить транзакцию, или кто вручную добавляет данные из PhpMySQLAdmin и т.п.) согласно заданной логике.
-) Нужно хорошо знать БД (где и что она хранит и т.п. ;) )
Вопрос производительности не имеет однозначного ответа, так как зависит от многих факторов (ресурсы и текущая нагрузка сервера, частота изменений ...)

Примерно так (пишу с левого компа, где нет mysql - если что отредактируйте немного)

select product_id as id, products.name,
  group_concat(sizes.value separator ';') as sizes 
from product_sizes, sizes, products 
where product_id=products.id and size_id=sizes.id 
group by product_id

Добавлено после комментария автора топика:
Если необходимо выводить и те товары , у которых не указан размер, тогда:

select products.id, products.name, 
  group_concat(sizes.value separator ';') as sizes 
from product_sizes 
  inner join sizes on (size_id=sizes.id) 
  right join products on (product_id=products.id) 
group by product_id order by id;

Можно и другим "монстром" :-)

select substring_index(st1, ' ', length(st1) - length(replace(st1,' ',''))) as alt ....