Windows.Web.Http is a WinRT API available in all the WinRT programming languages supported: C#, VB, C++/CX and JavaScript. This enables the option to write the same code in the language of your choice.

System.Net.Http is a .NET API, and it is only available for C# and VB developers.

Windows.Web.Http advantages

• WinRT APIs are written in native code, which translates in better performance.
• Windows.Web.Http is on top of a common Windows HTTP stack, and reuses resources already in use by other Windows components. System.Net.Http is a separate implementation of the HTTP protocol that is not frequently used by other Windows components. So, in some cases, you save resources by choosing Windows.Web.Http.
• Windows.Web.Http has better integration with WinRT types, such as IInputStream, IOutputStream and IBuffer. Avoiding the .NET extensions that convert System.IO.Stream into IInputStream or IOutputStream and System.Array into Windows.Storage.Streams.IBuffer can improve performance and save resources in some cases.
• Windows.Web.Http has the new features, such as HTTP/2 support.
• Windows.Web.Http is COM based and can be used by any programming language that understands COM.

System.Net.Http advantages

• System.Net.Http is available since Windows 8 or .NET 4.5 and Windows.Web.Http is only available since Windows 8.1 and Windows Phone 8.1.
• It is straight forward to port WinRT code using System.Net.Http to ASP.NET or Xamarin (Portable Class Library)
• Windows 8 and 8.1 projects or desktop projects: †
  • Authentication headers and credentials are isolated per HttpClient (example)
  • Cookie container isolated per HttpClient
  • Does not cache HTTP responses, so subsequent requests will never come from the cache, a common issue with servers that does not set the correct Cache-Control header (example)
  • Works with System.Net.NetworkCredential

† For Windows Universal Projects (UWP), System.Net.Http is a wrapper on top of Windows.Web.Http, as described here.

Further reading: Demystifying HttpClient APIs in the Universal Windows Platform

There is not much to find about it. Some things that come in my mind:

• The new API doesn't have dependencies to some low-level Windows functions, like the current API does.
• The new API is better capable handling new methods related to the HTTP protocol, like WebSockets, etc.

Some useful information can be found in this blog post which also referenced this Build video. They speak about better cache control, and a way to add filters for authentication, easy access to cookies, reconnecting, etc.