No InnoDB, qualquer índice secundário contém internamente a coluna de chave primária da tabela. Portanto, o índice nome na coluna (nome) está implicitamente nas colunas (nome, id).

Isso significa que EXPLAIN mostra seu acesso à tabela de categorias como um "index-scan" (isso é mostrado no tipo coluna como "índice"). Ao varrer o índice, ele também tem acesso à coluna id, que usa para pesquisar linhas na segunda tabela, item.

Em seguida, ele também aproveita o índice do item em (category_id) que é realmente (category_id, id), e é capaz de buscar item.id para sua lista de seleção simplesmente lendo o índice. Não há necessidade de ler a tabela (isso é mostrado no Extra coluna como "Usando índice").

O MyISAM não armazena chaves primárias com a chave secundária dessa maneira, portanto, não pode obter as mesmas otimizações. O acesso à tabela de categorias é do tipo "ALL", o que significa uma varredura de tabela.

Eu esperaria que o acesso ao item da tabela MyISAM fosse "ref", pois ele procura linhas usando o índice em (category_id). Mas o otimizador pode obter resultados distorcidos se você tiver poucas linhas na tabela ou se não tiver feito ANALYZE TABLE item desde a criação do índice.

Re sua atualização:

Parece que o otimizador prefere uma varredura de índice em vez de uma varredura de tabela, então ele aproveita a oportunidade para fazer uma varredura de índice no InnoDB e coloca a tabela de categorias em primeiro lugar. O otimizador decide reordenar as tabelas em vez de usar as tabelas na ordem que você forneceu em sua consulta.

Nas tabelas MyISAM, haverá uma varredura de tabela em qualquer tabela que ela escolher acessar primeiro, mas colocando a tabela de categorias em segundo lugar, ela se juntará ao índice de chave PRIMARY da categoria em vez do índice secundário do item. O otimizador prefere pesquisas a uma chave única ou primária (tipo "eq_ref").