After the birth of Silverlight the developers have had to deal with asynchronous programming much more than before. The responsiveness of the user interface has always been an important matter and asynchronous programming has been the right response also before than Silverlight, in Windows Forms and WPF. But for the first time, Silverlight made a strict request by the framework to run a lot of tasks asynchronous. Due to architectural choices, all the calls to the network API had to be made in an async way, and this caused a number of headaches to developers that for the very first time couldn't forget about asynchronicity paying the price of a bad user experience.
In metro-style applications, the concept of "make it asynchronous" is exploded to the extreme consequences. WinRT, the underlying wrapper for Windows API, request to run asynchronously most of the tasks, with the rule that, if it may run longer than 50 milliseconds, then it has to be asynchronous. Calling the network, using a device, grabbing a photo from the camera, all these actions are asynchronous in metro-style applications but, async is hidden also behind simpler tasks like opening a message box.
All this surfeit of asynchronous, promises to make programmer's life a hell. Luckily, the .NET framework 4.5 introduces a set of tools to the rescue, making asynchronous simpler as drinking a glass of water.