O que você está vendo é, infelizmente, um problema geral com a forma como as funções espaciais são implementadas no MySQL e uma fraqueza relacionada com subconsultas envolvendo funções espaciais.
Para que as funções Contains e Intersects funcionem corretamente e para que o índice seja usado, você precisa que uma das geometrias seja uma constante. Isso não parece estar documentado, embora todos os exemplos que você verá com o MySQL com Intersects/Contains funcionem dessa maneira.
Então, você não pode escrever algo assim, como poderia no Oracle Spatial ou Postgis,
select a.*, b.*
from sometable a, someothertable b
where ST_Intersects(a.geom, b.geom)
and a.someattribute=... and b.someattribute=...;
Em tal consulta, se as tabelas a e b tiverem índices espaciais, eles serão usados, desde que isso seja mais restritivo do que algum outro atributo que você possa colocar na cláusula where.
O mesmo se aplica para autojunções, onde você deseja encontrar todos os polígonos que se cruzam com todos os outros polígonos em uma tabela com base em algum atributo, por exemplo,
select a.*
from sometable a, sometable b
where ST_Intersects(a.geom, b.geom) ....
Então, no MySQL espacial você é forçado a ter uma das geometrias como uma constante.
Como um aparte, a sintaxe de junção esquerda não faz muito sentido com espacial (embora seja suportada), pois você não está realmente unindo em um único atributo correspondido, mas em um operador de contenção/interseção bidimensional.
Além disso, tenho certeza de que em sua junção interna o índice não está sendo usado, se você observar a
key e rows saída de explicar. 
