We're talking about deployment to production machines - what's the difference between 3 seconds and 5 minutes? Your machine is sitting on a fat pipe in a datacenter, where you can push a 300MB deploy (which is a LOT) trivially. I highly doubt you're rolling out code changes every 10 minutes... not to production anyway.
Sending diffs removes your ability to roll back at all, or if you're somewhat devious about it, it still wouldn't allow you to roll back more than a single version.
I'm surprised you're so concerned about time-to-deploy for an action that happens, what, once a day at most? Twice? The amount of safeguard you gain for the trivial non-human-time (it's not as if some guy is sitting there copying files) increase is pretty massive.
As other people mentioned, if you send the diff by, say, pulling from your git repository, then you can roll back to any tag or revision.
What happens when your 300MB deploy needs to be pushed from your development machine out to 15 different production servers? I wouldn't want to send ~4.3GB for every deployment. Furthermore, a quick deployment time is valuable when a crucial fix needs to be pushed to production.
This is not to mention the space that your 300MB deploy is going to take up on the hard drives of your production machines if you deploy twice a day. That's over 213GB a year per machine, sounds like you would need to start deleting old revisions. Or start just sending the diffs.
I use svn export for deployments - all sorted by revision into static cached directories, then symlinked to HTTP root.
This has the added advantage of being able to roll back to any previous version instantly.