I'm sorry, yes you are correct. It should sign 20.

You are also correct that we do not get general partial replication. sometimes it works, sometimes a partial peer is able to provide a proof anyway, but there are some times it doesn't work. Merkle trees are most typically used in applications where there is, by design, a number of full nodes that have everything and then light weight clients who trust but verify.

Although, if the default is to replicate a whole feed, and partial replication is only used around the edges then it would probably still work anyway, because you'd usually be able to find someone with a full feed. But if everyone was doing sparse partial replication, that probably wouldn't work. The question really, is what proportion of the time does it not work? which is really an application question - the worse case is probably if peers want a few random messages, but that's probably not the usual case.
To make a model of what the usual case might be, you need to think about how possible applications are likely to use it.

Security of ooo:

I think the answer here is that out-of-order messages have a different security interpretation. They are only secure if you already know you want their hash. in-order-messages are considered secure if you know the public key they are signed with.
ooo messages actually have a stricter security requirement!

For example, key compromise doesn't effect ooo messages, because their hash doesn't change. After key compromise, we can't trust new messages we see for a feed (which may have fake old timestamps and low sequence numbers) but we can still trust that messages
replied to (thus hashed, like ooo messages).
ooo messages will still be just as secure as they are now when quantum computers become available. If we requested ooo messages by key and sequence number, then I'd agree, they'd have relaxed security, but hashes actually significantly stronger than signatures.

in-order-messages are for when we explicitly care about future messages signed by that key, we're trusting the key. but in ooo we explicitly do not care about future messages, we are not trusting anything, just that there isn't a hash collision.