The variable skip_replication has two important properties:
it's written into the binary log;
it cannot be changed inside a transaction.
SET STATEMENT recognizes the latter and does not allow to change it inside the transaction.
However, when it's applied outside a transaction, it works and is written into the binary log. But look how it looks in there:
That is, it is written after BEGIN and before COMMIT, hence inside a transaction. So, when the binlog is replayed, the replaying server chokes on it.
It does not seem to affect replication – somehow it magically works. But when the binlog is used as a backup, it's a problem.
Compare with how it's written in case of a "normal" SET:
Percona server does not have the variable, so nothing to compare with.