Currently /UpdateSource allows you to minimize the number of steps to take to get fully patched when you are laying down a *brand new* instance of SQL Server.
This doesn't help reduce steps if you've already installed the product and want to apply, say, SP1 and SP1 CU1. /Action=Patch and /UpdateSource are incompatible switches, so what you must do is install Service Pack 1, then install Cumulative Update 1 separately.
To add insult to injury, you must perform a restart in between these two steps, even in the case where the file checker during SP1 setup does not find any files in use that would require a restart.
Slipstreaming for the core product during an initial install is great, and a massive time-saver. But I would argue that slipstreaming during a service pack installation is even *more* important, because downtime during servicing or maintenance windows needs to be as minimal as possible. Since SP1 requires a reboot before applying CU1 (see https://connect.microsoft.com/SQLServer/feedback/details/774111/cumulative-update-requires-a-restart-after-sp1-install), this is certainly going to be critical for a lot of businesses where downtime is an issue.
I also blogged about these issues here: