Q:

Does Datomic ship all transactions to all connected peers on "commit"?

The Datomic transactor pushes live changes to all connected peers to maintain a Live Index.
Does that mean that all data that gets transacted will always be sent to all peers connected - interested in the data or not? Or is it only e.g. the most recent db transaction id?

A:

The empirically reached answer: Yes, the full contents of all transactions (and more *) gets streamed to all connected peers.
I confirmed that by connecting a peer A to a transactor and let it either 

just sit there, staying connected OR
monitor transactions by means of tx-report-queue OR
monitor transactions and print all attribute values of all entities that were modified in the transaction

Concurrent to each of the above test runs, a peer B would execute 4 transactions, where each transaction would change a couple of simple properties of a single entity, one of the attributes being the about 5k random string data, the other attributes just really short strings.
Wireshark captured the TCP connection between Peer A and the transactor, and the total byte size of the tcp dumps can be seen in the following table.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  case  tx-report-queue  print  bytes (5kB)  bytes (13kB) 
──────────────────────────────────────────────────────────
     1                                61348        127996 
     2  ✓                             61800        128084 
     3  ✓                ✓            61260        127652 
──────────────────────────────────────────────────────────
 no-tx                                13076         12988 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The relative dump sizes differ by less than 500 Bytes, which is far less than even a single of the 4 committed transactions, that change more than 5kB each, incur.
I then also ran the test without doing any transactions, and the tcp dump would then shrink to about 13kB. I therefore take it that it is transaction data being transmitted.
*) Back-of-the-envelope: The per transaction cost of transactor<->PeerA data was about (61kB-13kB)/4tx = 12kB/tx. So it looks that when changing a property, both the retraction (5kB for that one string) and addition (again 5kB) are transmitted via the transactor's live index, which would give about 10kB, plus a little spare room of 2kB for the other (much smaller) modified attributes, (plus some more heart beats, which occur every 5 seconds and add some 300 Bytes, in the test cases where transactions were performed, just because of the time I took to run those tests).
Edit To put my inferences on more solid a foundation, I reran the tests with a 13kB string instead of the original 5k. The results (added to the table) seem to confirm my theory: Now the per-transaction cost is about (128kB-13kB)/4tx = 29kB/tx, so 13kB retraction + 13kB addition + 3kB slack.

Further Edit I ran some more tests, graphing the bytes received by the respective PeerA*s. Both traffic from the transactor, which was done via a single TCP connection, and traffic from the datomic:free:// (i.e. H2) storage, which in all cases involved three TCP connections to the same H2 port.
I ignored TCP traffic in the direction of the transactor and storage, which was much less.

PeerA1 starts with an empty database

monitors transactions via [tx-report-queue]
prints all attribute values of all entities modified in every transaction
queries all elements in the database every 4 seconds

PeerB performs the above 13kB string attribute change and a few other very small attribute changes every 6 seconds
PeerA2 starts with a populated database and PeerB still running

monitors transactions via [tx-report-queue]
prints all attribute values of all entities modified in every transaction

PeerA3 starts with a populated database and PeerB still running

monitors transactions via [tx-report-queue]

PeerA4 starts with a populated database and PeerB still running

does nothing besides connecting to datomic and waiting

And here's a chart of the rx traffic (of the PeerA*s):

How I read the chart:

the transactor always pushes tx data on commit, whether PeerA is interested in it or not
the transaction data contains, in addition to the data "additions", the implicit retractions (that's why the first transactor spike after starting PeerB is only half the size of later spikes - the first time there is no data yet, hence nothing to retract)
storage is only used initially to read (from the log in storage - not from the index - as the data in the database is always much less than memory-index-threshold=32m, i.e. indexing will not kick in during the test)
storage is not used when PeerA1 queries the database; in fact, the queries do not incur any noticable network traffic
storage read size when starting the peers grows as the db accretes data (regardless of the fact that data is "overwritten" -> datomic history)

