Note by "queuing and batching" Spotify may be aggregating events client-side. Given that messages are priced in 64K increments, it would be most cost efficient to to get each message as close to 64K as possible.
i.e.
# serialized: 1 message, 1 op
publish("['foo', 'bar']")
# instead of:
# a) 2 messages, 2 ops
publish("foo")
publish("bar")
# b) 2 messages, 1 call, 2 ops
publish("foo", "bar")
Yes then it would be down to their consumers to split them out. However, the graphs Spotify show from Google's monitoring do not support this and they show the actual volume of messages as quoted in the article.
I agree that the current graphs from Spotify don't support this. They do seem to show a one-to-one mapping between events and messages emitted. Given the comparison in my GP, I think that client-side message collation/aggregation would be a natural next step.
i.e.