Q:

Why doesn't the C# Standard Library (mscorlib) provide abstractions for its classes?

The C# standard library currently does not provide abstractions/interfaces for most of its offerings, such as File, HttpClient, etc. (Actually, I'm not certain that this is the case with VB.NET, F#, etc., so let's stick with C# for now.) Yet, the demand is quite high, as unit testing practically requires you to mock out dependencies to IO, network, etc. There are quite a few homebrew solutions, most of them "wrappers."

System.IO.Abstractions
SystemWrapper

What I'm curious about is why the standard library does not make this easier by simply including the interfaces within the library. Are there design reasons? Stylistic?

A:

Quite simply, Microsoft couldn't have anticipated the widespread use of dependency injection and unit testing back when they first built the .NET framework.
But this is a common problem, not just for native .NET types but for those in 3rd party libraries as well. A common technique for dealing with types that have no abstraction is to use the adapter pattern to make an abstraction. Then you only need to use your built-in type instead of the library type.
Example: UrlHelper
In MVC 4 and before the UrlHelper class did not have virtual members, so it couldn't be mocked or injected. To work around this, one only needs to create an interface with the same members (this can be done easily using the "extract interface" feature in Visual Studio)...
public interface IUrlHelper
{
    string Action(string actionName);
    string Action(string actionName, object routeValues);
    string Action(string actionName, string controllerName);
    string Action(string actionName, string controllerName, object routeValues);
    string Action(string actionName, string controllerName, object routeValues, string protocol);
    string Action(string actionName, string controllerName, RouteValueDictionary routeValues);
    string Action(string actionName, string controllerName, RouteValueDictionary routeValues, string protocol, string hostName);
    string Action(string actionName, RouteValueDictionary routeValues);
    string Content(string contentPath);
    string Encode(string url);
    RequestContext RequestContext { get; }
    RouteCollection RouteCollection { get; }
    string RouteUrl(object routeValues);
    string RouteUrl(string routeName);
    string RouteUrl(string routeName, object routeValues);
    string RouteUrl(string routeName, object routeValues, string protocol);
    string RouteUrl(string routeName, RouteValueDictionary routeValues);
    string RouteUrl(string routeName, RouteValueDictionary routeValues, string protocol, string hostName);
    string RouteUrl(RouteValueDictionary routeValues);
    bool IsLocalUrl(string url);
    string HttpRouteUrl(string routeName, object routeValues);
    string HttpRouteUrl(string routeName, RouteValueDictionary routeValues);
}

... and then create an adapter type that inherits UrlHelper and implements IUrlHelper...
public class UrlHelperAdapter : UrlHelper, IUrlHelper
{
    private UrlHelperAdapter(RequestContext requestContext)
        : base(requestContext)
    {
    }

    public UrlHelperAdapter(RequestContext requestContext, RouteCollection routeCollection)
        : base(requestContext, routeCollection)
    {
    }
}

Once this is done, you can pass IUrlHelper to any method or constructor, and you need only pass UrlHelperAdapter as the concrete type (or if using a mocking framework, build a mock of IUrlHelper).
This technique will work for most non-static types that don't have abstractions.
As you have already discovered, there are entire libraries out there that do the legwork for you by building their own adapters, and there is nothing wrong with using them if it saves you some steps.

As mentioned in the comments, IO.Stream already is an abstraction so there is no need in that specific case.

