Pointen er ikke, om potentielle dårlige situationer er sandsynlige. Pointen er, om de er mulige. Så længe der er en ikke-triviel sandsynlighed for, at problemet opstår, bør det undgås, hvis det er kendt.
Det er ikke sådan, at vi taler om at ændre et funktionskald på én linje til et monster på 5000 linjer for at håndtere en eksternt mulig edge-case. Vi taler om faktisk at forkorte opkaldet til en mere læsbar og mere korrekt brug.
Jeg er lidt enig med @Mark Baker i, at der er nogle præstationsovervejelser, men siden id er en primær nøgle, MAX forespørgslen vil være meget hurtig. OK, LAST_INSERT_ID() vil være hurtigere (da det kun er at læse fra en sessionsvariabel), men kun med en ubetydelig mængde.
Og du behøver ikke mange brugere for at dette kan ske. Alt du behøver er en masse samtidige anmodninger (ikke engang så mange). Hvis tiden mellem start af indsatsen og starten af valget er 50 millisekunder (forudsat en transaktionssikker DB-motor), så behøver du kun 20 anmodninger i sekundet for at begynde at ramme et problem med dette konsekvent. Pointen er, at vinduet for fejl er ikke-trivielt. Hvis du siger 20 anmodninger i sekundet (hvilket i virkeligheden ikke er meget), og antager, at den gennemsnitlige person besøger en side i minuttet, taler du kun om 1200 brugere. Og det er for at det skal ske regelmæssigt. Det kunne ske én gang med kun 2 brugere.
Og lige fra MySQL-dokumentationen på emnet :
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.