The statements might arrive at the slave in a different order and the
slave might serialize the transactions differently--for a start.

Some things to think about:

1. Queries aren't the only way data is loaded into a database; bulk
data loading, for example.

2. Query shipping (as it's called) requires that identical versions of
the database schema are maintained on every node. Dropping or creating
a trigger in one place but not all places will affect query semantics.
Talking to DBAs, they don't want to do this, as one frequent use for
replication is to maintain an analytic-queries-only copy of some
operational store.

3. What happens if the data on the two nodes is different? Consider a
many-to-one replication from a number of retail stores to a central
warehouse. Queries on child-node A (which has a sub-set of the overall
database) might affect a different (much larger) data set on the
parent-node.

Folk who design replication schemes need to consider a broader range
of deployment scenarios than the one you've described. Frankly, in
your situation. query shipping would be a better solution (assuming
you have no view, triggers, stored procedures etc). But log sniffing
hits a broader set of the cases customers seem to care about.

I'm implementing my own database, and therefore i was thinking about
the same question. (i have not yet implemented recovery, because
there's so much other stuff to do).

Currently my idea is to send the log over the net, because in my
design i do not log physical pages, instead i just log the modified
key/record items.

Of course i could also send the queries, but that's way more complex
to implement. Assume you want to insert a few items into your local
database. The query is sent to the remote node, and in case of success
it's also inserted locally. If you send the query to the remote node,
but then don't receive an answer because your network switch exploded,
you do not know which part of the query (if any) was already executed,
and then recovery becomes difficult (and network problems happen very
often).

If you send the log, recovery is easier because each log entry has a
unique ID (lsn - log serial number) and can be applied atomically.