Yes, yes...I know what you are about to say:

a) transactions slow down the database
b) you can use locking in MySQL
c) you don't really need them anyway.

Inserts are way faster without transactions, true, but what do you do when one insert out of ten fails? Like, the order goes into the invoice table, but not the delivery table, because that insert fails?

Locking, you say. Well, avoiding deadlocks while using locking is easy as long as your system is rather small, and as long as there is only one developer working on it, someone who can keep track of everything in his/her head. With increased complexity the chance of a deadlock situation increases exponentially, and in practise, only having locking means you are restricted to a singleton pattern for database access. Not especially scalable, although a bit easier to implement.

I tend to miss subselects, too, although that is, AFAIK, being implemented.

You do need transactions for anything that grows beyond your pet project, and MySQL doesn't provide it. It is, though, lighting-fast and very durable.