HTTP Strict Transport Security (HSTS), is a way to signal to a web client that valid HTTPS certificates must be used when connecting to a domain. There are two main benefits to HSTS. First, it prevents a user from connecting over an unencrypted HTTP connection. Unencrypted HTTP leaks data to the network and is vulnerable to manipulation in man-in-the-middle attacks. Second, it prevents a user from connecting if the server presents an untrusted TLS certificate. Users aren't great at deciding if a warning message about an untrusted TLS certificate is a security concern or just a misconfiguration. They don't have the knowledge or tools to decide, and they may inadvertently allow an attack to proceed by clicking through the warning.
A site that deploys HSTS has determined that it can encrypt all its web traffic with HTTPS and accurately manage its certificates.
HSTS preload is a mitigation against a very specific attack. A web browser needs to talk to a web server to see if it has HSTS headers. Once it does, it can cache those headers and it will be protected through the max-age expiration. However, that first load is vulnerable as the HSTS policy is not yet known (the bootstrap man-in-the-middle vulnerability). A malicious network operator could block HTTPS on port 443, for example, to try to trick browsers into thinking sites don't support TLS. Web browsers ship with a large hardcoded list of domain names known to support HSTS: the HSTS preload list. As such, the first load of these websites can be protected.
Let's look at some stats
I want to call out a couple of things. Only eight of the top twenty domains are on the Chrome HSTS preload list. Half aren't using HSTS at their apex domain at all. Yahoo and OpenAI are using the HSTS headers, but they aren't on the preload list.