SERIALIZABLE transaction information leak via serial
For various performance and concurrency reasons, sequences are non-transactional, but atomic. In other words, they always give a distinct value to each session, but they don't reuse values, nor are they "gapless" where they return a continuous sequence of numbers.

The second transaction in your example was handed distinct sequence values for each of the rows inserted, and since that is atomic, but non-transactional, the first transaction sees the sequence's nextval increased even though the transaction isolation level is SERIALIZEABLE. 

The behavior is noted at the bottom in the Sequence Manipulation Functions documentation.

Neil Conway also explains this quite well in his post FAQ: Using Sequences in PostgreSQL, including a link to a method of creating a "gapless" sequence that should behave how you had initially expected, but at the cost of some concurrency and performance.