What causes pt-online-schema-change to slow down the further it gets through a table?
A guess...  The Change Buffer is full and overflowing.

The operation is building 11 secondary indexes.  For InnoDB, the building of secondary indexes is "delayed" by storing to-do info in a part of the buffer_pool called the Change Buffer.

Eventually the "changes" need to be flushed to disk.  Your table is probably much bigger than the buffer_pool, so it is probably overflowing.  Here's (roughly) how the 11 indexes for a given row are being created for the new table:


Write 11 records to the Change Buffer.  Such a record is (I guess) the secondary key column(s) plus the primary key column(s).
Check for overflow.  If running out of room (which you are by now), read some index block from disk, fold the index entries into it, queue the block for writing back to disk, and free up the index entries from the Change Buffer.


Initially all 11 indexes were empty, so the above process was dumping blocks full of stuff out to disk -- very efficient.

As the processing continues, the indexes get bigger, and the "dumping of more entries" becomes less efficient because there are more blocks to deal with and few records to put in each one.  That is, each read-modify-write step is freeing up fewer and fewer entries from the Change Buffer.

This feeds back to slowing down the processing, which pt-online-schema-change smartly turns into smaller chunk sizes.

Alternatives


It is sometimes better to rebuild indexes after building the table.  However, you probably don't want to because it would involve downtime.
In 5.6 (and more in 5.7), many ALTERs can be performed with very little impact on the running system.  5.5 is now the oldest supported version; you should consider upgrading.  (Pt-online-schema-change is still be useful for cases where online alters do not apply.)
Vertical partitioning -- Instead of adding columns to this table, you could have considered building a 'parallel' table with the new columns.  This can usually be done with no downtime.  Although some SELECTs will need a JOIN, this is not necessarily a performance burden.