Дело не в том, возможны ли потенциально плохие ситуации. Дело в том, если они возможны. Пока существует нетривиальная вероятность возникновения проблемы, если она известна, ее следует избегать.
Мы не говорим об изменении однострочного вызова функции на монстра в 5000 строк, чтобы иметь дело с удаленно возможным краевым случаем. Мы говорим о том, чтобы сократить вызов до более читаемого и более корректного использования.
Я вроде бы согласен с @Mark Baker, что есть некоторая оценка производительности, но, поскольку id является первичным ключом, запрос MAX будет очень быстрым. Конечно, LAST_INSERT_ID() будет быстрее (поскольку он просто читает из переменной сеанса), но только на тривиальную величину.
И вам не нужно много пользователей, чтобы это произошло. Все, что вам нужно, это много одновременных запросов (даже не так много). Если время между началом вставки и началом выбора составляет 50 миллисекунд (при условии, что ядро БД безопасно для транзакций), то вам нужно всего лишь 20 запросов в секунду, чтобы начать последовательно решать проблему с этим. Дело в том, что окно для ошибки нетривиально. Если вы говорите 20 запросов в секунду (что на самом деле не так уж много) и предполагаете, что средний человек посещает одну страницу в минуту, вы говорите только с 1200 пользователями. И это для того, чтобы это происходило регулярно. Это может произойти только с двумя пользователями.
И прямо из MySQL документации по теме :
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.