Short Version: if you are running backups against a busy server, then YES.
If you lock the server from updates, ie is a slave and do mysql -e "STOP SLAVE" before the backup, I suspect the xtrabackup_logfile would be empty and apply-log would do nothing.
Longish version:
There is a doc providing an example of making a backup and restoring it, as part of a howto on preparing a slave for replication, and that indicates that IT IS required to add a step to apply the logs before they are available for use;
innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir
innobackupex --user=yourDBuser --password=MaGiCdB1 /
--apply-log /path/to/backupdir/$TIMESTAMP/
The options page for innobackupex indicate that --apply-log reads transactions from the xtrabackup_logfile
Prepare a backup in BACKUP-DIR by applying the transaction log file
named xtrabackup_logfile located in the same directory. Also, create
new transaction logs. The InnoDB configuration is read from the file
backup-my.cnf created by innobackupex when the backup was made.
I suspect that xtrabackup_logfile contains the transactions during the period that the backup was running but the database was not locked. I think by this strategy that innobackupex can run with only a short lock time, and use the binlog to apply the updates to the backup retrospectively.
The xtrabackup-manager tool applies the log has a apply-log step in this file here;
http://code.google.com/searchframe#i12s1rWpN4M/trunk/includes/genericBackupTaker.class.php&q=apply%20log%20package:xtrabackup-manager.googlecode.com
Its not clear what format these files are (file xtrabackup_logfile returns "data"), though they seem to be sparse on my system, but I don't expecting any pending transaction in this case because the backups are taken from a stopped slave. Though if you wanted to find out, the source code of xtrabackup is available for inspection.
