“Serializability: multi-operation, multi-object”, but why?

Martin Kleppman in Designing Data-Intensive Applications (p. 329) tried to distinguish serializability from another slippery database concept, linearizability. The latter is not of any interest to us in this article, but what we are interested in his summary of serializability (italics in the original, the bold is mine):

Serializability is an isolation property of transactions, where every transaction may read and write multiple objects (rows, documents, records) [...] It guarantees that transactions behave the same as if they had executed in some serial order (each transaction running to completion before the next transaction starts). It is okay for that serial order to be different from the order in which transactions were actually run [12].

But why is serializability (only) relevant to multi-object transactions? Naturally, I followed the reference [12]...

This leads us to a 2014 article by Peter Bailis: Linearizability versus Serializability. Bailis writes has a section titled “Serializability: multi-operation, multi-object, arbitrary total order”, and he writes:

Serializability is a guarantee about transactions, or groups of one or more operations over one or more objects. It guarantees that the execution of a set of transactions (usually containing read and write operations) over multiple items is equivalent to some serial execution (total ordering) of the transactions.

But still, why? In fact, the first sentence implies that serializability is relevant to single-operation, single-object transactions.

Serializability is relevant to single-operation, single-object transactions too. But in this case serializability is almost trivial. Consider that the weakest isolation level is read committed (serializability is the strongest isolation level). Read committed gives us the following guarantees:1

When reading from the database, you will only see data that has been committed (no dirty reads).
When writing to the database, you will only overwrite data that has been committed (no dirty writes).

Assuming read committed, if you have transactions that each contains only a single operation over a single object, then you have serializability too! Let's examine all possible scenarios:

If you have a transaction that reads, call it R, and one that writes, call it W, then either R will read the data as it was before W started, or after W commits. Why? Because there are no dirty reads; it won’t read an intermediate, uncommitted state. But in this case, either R will complete fully before W, or the other way around, and thus they are serializable.
Similarly, if you have two transactions W1, W2 that both write to the same object, then either W1 will write before W2, or the other way around. In either case, they are serializable especially because neither will overwrite uncommitted data as there are no dirty writes.

This generalizes to multiple transactions, and so in all cases the transactions will be serialized

Read committed, and other weak isolation levels, are actually weaker than serializability only when we have at least one of the following: multiple operations or multiple objects. For example, consider the following scenario: there's a transaction T1 that has two (non-parallel) operations (multi-operation), each reading a single object, O1 and O2 respectively. There is also another transaction T2 which also has two single-object operations, each modifying O1 and O2, respectively. Read committed allows T1 to read O1 before T2 has committed, but read O2 after T2 has committed. Why? Because only one transaction writes, so we can't have any dirty writes, and there is no dirty read because T1 reads only committed data; it reads O1 as it was before T2 started—so it doesn't read any intermediate state—and it reads O2 after T2 has committed, so again it reads committed data. This, however, is non-serializable, because in a serializable scenario either T1 would read both O1 and O2 before T2 commits, or vice-versa.

A practical example in which this effect manifests is shown in Figure 7-6 of Designing Data-Intensive Applications. But what matters is the general idea, which is that with read committed, if you have multiple operations or multiple objects in a single transaction, one object/operation can be accessed/performed before another transaction, but the other object/operation can be accessed/performed after that same transaction. This is what makes it non-serializable. If there was a single operation on a single object, then that would be committed fully either before or after other transactions.