I assume that you understand the benefits of HTTPS over HTTP.
HSTS provides a means to tell clients to always use HTTPS when interacting with a site.
There are 2 ways a client can find out if it should only use HTTPS to access a website. It can check a registry of site (preload) or it can visit the site (over either HTTP or HTTPS) and receive a header announcing the site uses HSTS. Once the client has seen the site uses HSTS, it should remember this for a length of time (the header specifies an TTL - but the client may drop the information before this TTL expires, like any cache).
Once a HSTS-aware client knows that a site is subject to HSTS, it will automatically change any request it makes to that site from HTTP to HTTPS. Despite what it says on the OWASP site, this is not a redirect - that's something quite different in HTTP, nor is it proxying; the URL is changed in the client before being handed off to the request dispatcher. Depending on the implementation, this may appear as a redirect to the higher logic layers of the client, but no request has ever been sent at this stage in processing.
If your browser knows your favourite online store uses HSTS and a MITM is able to present a HTTP link to that site which you click on, your browser automatically upgrades the protocol, preventing most of the bad things which could happen in the absence of SSL - i.e. the MITM from reading your password, modifying the content sent back from the server, or injecting fake requests using your credentials.
Using pre-load provides the most secure implementation, but even in the header response, because your client remembers the status, HSTS is still effective.