I looked inside the the built in WebApplicationBuilder class and noticed the
public ILoggingBuilder Logging { get; }

property. Here is the entire ILoggingBuilder interface:
public interface ILoggingBuilder
{
    IServiceCollection Services { get; }
}

It just stores a single property so what is the point of this interface? Couldn't the WebApplicationBuilder just store an instance of IServiceCollection directly?

What is the point of the ILoggingBuilder interface in ASP.NET Core?
It's about scoping and reducing intellisense hell. If everything was on IServiceCollection it would get cluttered quickly. Subsystems that are highly configurable and are themselves extensible need a "target" to extend. This is one of the patterns the platform employs to solve this problem.
Some of the patterns you'll see:
Simple options via a callback:
services.AddComponent((ComponentOptions options) => 
{
    options.SomeFlag = true;
});

This pattern works well when the number of options on component is small, self-contained and has limited extensibility.
Complex builder returned from the API:
IComponentBuilder builder = services.AddComponent();

builder.AddExtensibleThing1();
builder.AddExtensibleThing2();

Breaks the fluent API pattern but reduces nested lambdas.
OR
services.AddComponent((IComponentBuilder builder) =>
{
    builder.AddExtensibleThing1();
    builder.AddExtensibleThing2();
});

Similar to the above but nested instead of a return value. Keeps the fluent API working at the cost of more callbacks.
