A question came up in the Technet forums around content caching, and what variables exist to adjust it. The footprint of cached content on the wSUS/SCE server take into consideration four variants:
SCE default configuration will bring in nearly 8GB of content; provided your needs stay within one language.
...Now about Express files..
There are two ways that a package can install on your managed systems; Stand-alone, or Express. For stand-alone, all the possible changes which can happen during that installation are contained in the package. Let's say Foo.Dll is revising to 1.2, and Bar.Exe is revising to 1.3. In this case, the old Foo.Dll and Bar.exe would be removed from the system, and the new ones applied. This is the safest, and most common way patching happens. However, it means that the entire package travels across the LAN/WAN when installation is necessary.
In the Express scenario, it may be that Workstation1 already had Foo.dll version 1.2, but not the latest version of Bar.dll. It's neighbor, Workstation2 had just the opposite. If the EXPRESS files were present, Workstation1 and 2 would ask the SCE/WSUS server for only the binary ranges it needed, and the acutal bytes which went across your LAN/WAN would be very close in footprint to the bytes which were needed to simply replace the specific files targeted.
So, Express seems to be the winner here (almost). In order to provide this optimization, the Update Services infrastructure needs to have fault tolerance. Express packages will not work for 100% of the systems in need of patching. Therefore, enabling express option means that the system will download the standalone version of an update as well as the Express version of that update. Should it need to fall-back due to failure, the standalone version will be locally available. Also, the express files are 2-4 times as large as the standalone packages.
The tradeoff question is: Should the optimization target ingress to the WSUS server at the cost of more LAN/WAN traffic, or the converse?