A questão não é se situações ruins em potencial são prováveis. A questão é se eles são possíveis. Enquanto houver uma probabilidade não trivial do problema ocorrer, se for conhecido, deve ser evitado.
Não é como se estivéssemos falando sobre mudar uma chamada de função de uma linha em um monstro de 5.000 linhas para lidar com um caso limite remotamente possível. Estamos falando de encurtar a chamada para um uso mais legível e mais correto.
Eu meio que concordo com @Mark Baker que há alguma consideração de desempenho, mas desde
id é uma chave primária, o MAX consulta será muito rápida. Claro, o LAST_INSERT_ID() será mais rápido (já que está apenas lendo de uma variável de sessão), mas apenas por uma quantidade trivial. E você não precisa de muitos usuários para que isso ocorra. Tudo que você precisa é de muitos pedidos simultâneos (nem mesmo tantos). Se o tempo entre o início da inserção e o início da seleção é de 50 milissegundos (assumindo um mecanismo de banco de dados seguro para transações), então você precisa apenas de 20 solicitações por segundo para começar a encontrar um problema com isso de forma consistente. O ponto é que a janela de erro não é trivial. Se você disser 20 solicitações por segundo (o que na realidade não é muito), e assumindo que a pessoa média visita uma página por minuto, você está falando de apenas 1200 usuários. E isso é para que aconteça regularmente. Isso pode acontecer uma vez com apenas 2 usuários.
E diretamente da documentação do MySQL sobre o assunto :
You can generate sequences without calling LAST_INSERT_ID(), but the utility of
using the function this way is that the ID value is maintained in the server as
the last automatically generated value. It is multi-user safe because multiple
clients can issue the UPDATE statement and get their own sequence value with the
SELECT statement (or mysql_insert_id()), without affecting or being affected by
other clients that generate their own sequence values.
