El punto no es si las malas situaciones potenciales son probables. El punto es si son posibles. Siempre que exista una probabilidad no trivial de que ocurra el problema, si se sabe, debe evitarse.
No es como si estuviéramos hablando de cambiar una llamada de función de una línea a un monstruo de 5000 líneas para lidiar con un caso extremo remotamente posible. Estamos hablando de acortar la llamada a un uso más legible y más correcto.
Estoy de acuerdo con @Mark Baker en que hay cierta consideración de rendimiento, pero desde id es una clave principal, el MAX la consulta será muy rápida. Claro, el LAST_INSERT_ID() será más rápido (ya que solo está leyendo de una variable de sesión), pero solo por una cantidad trivial.
Y no necesita muchos usuarios para que esto ocurra. Todo lo que necesita es una gran cantidad de solicitudes simultáneas (ni siquiera tantas). Si el tiempo entre el inicio de la inserción y el inicio de la selección es de 50 milisegundos (suponiendo un motor de base de datos seguro para transacciones), entonces solo necesita 20 solicitudes por segundo para comenzar a encontrar un problema con esto de manera consistente. El punto es que la ventana de error no es trivial. Si dices 20 solicitudes por segundo (que en realidad no es mucho), y asumiendo que la persona promedio visita una página por minuto, solo estás hablando de 1200 usuarios. Y eso es para que suceda regularmente. Podría suceder una vez con solo 2 usuarios.
Y directamente desde la documentación de MySQL en el tema :
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.
