Can ISPs replace a website's HTML/JavaScript/HTTP headers with something else?

Your ISP is per definition a MITM (man-in-the-middle) and therefore can serve you any content it desires.

You mentioned HTTPS and this is of course a game changer. Yes, the ISP can server any arbitrary content when you access e.g. Facebook, but it does not have access to the private server certificate of Facebook and your browser will detect that it is not speaking to the correct server.

Now comes the critical part - the user will get a warning and has to decide what to do with it. If the user ignores the warning and tells the browser to load the fake website nevertheless, the browser will comply. A security aware user will realize that something strange is going on, leave the site and maybe even investigate further.

This means, your ISP can serve any content it likes, but as long as you are using state-of-the-art TLS encryption and validate server certificates, you have the ability to detect that some tampering took place.

Yes, they can. The important part is HTTP is still the default protocol in 2020.

Most sites use HTTPS today, but it works by first doing an insecure request which will redirect to HTTPS.

This means, since the ISP controls the default DNS server, the ISP can point to their own reverse proxy with their DNS server. This reverse proxy can do any manipulation you like.

It will of course be shown as "Not secure" in your browser, but you won't get the big scary certificate error.

This won't work for sites registered in the HSTS preload list (most or all of the big sites are), or if the user has visited the site before and the site has HSTS enabled.

Your ISP has complete control over traffic served. They can't tamper with any traffic without it being detected given the following conditions are true:

1. HTTPS is used for the request. If HTTP is used, then the ISP can control anything.
2. HTTPS traffic is allowed to the server. The ISP can refuse to forward secure traffic, pushing the user into choosing between accessing insecurely with the ISPs tampering, or not accessing the site at all.
3. The Certificate is securely validated. If the certificate is not validated securely, then the ISP can impersonate the web server, and there is nothing the web server can do.
4. The information the ISP wants is not located in the metadata (Subject alternative name, server IP etc).

For the first condition. Requesting using HTTP is still the default for many configurations, as the browser does not know if the site supports HTTPS outside limited conditions. Outside those limited conditions, the browser can not tell an ISP that is actively blocking HTTPS and tampering with HTTP requests from a site that does not support HTTP, so errors on the side of supporting existing sites. Those limited conditions are if a site is on the HSTS preload list (notable the .bank, .insurance, .dev, and .app tlds are on the list), or the user has previously visited the site on a non malicious connection to retrieve HSTS headers. Alternatively the user may have set there browser up (such as using the HTTPS everywhere extension) to disable the HTTP fallback.

For the second. If the ISP blocks the site, then for either a user may decide to accept the ISPs tampering in exchange for any service at all. Particularly if the user doesn't understand the risks, or relys on the ISP for IT support, this could easily happen.

The certificate is securely validated: This is the biggest weak point. The validation process relies on the user having a set of trusted CAs, which can be trusted such that any certificate they issue for almost any domain authenticates that domain. Any user/program with admin rights on a computer can install additional CA certificates, and this is common to see in corporate filtering environments. If an additional certificate is installed the issuing entity has the ability to impersonate any site. Kazakhstan has been attempting this at a government scale. This could be done by the ISP without the users understanding in the form of some form of parental controls or similar tooling.

Additionally the system uses complex code to parse and validate the certificate. Bugs are regularly found in this code and a malicious ISP could potentially exploit one.

Finally the metadata. In order to allow the request to be routed to its destination correctly, and because the ISP can clearly see and control all attempts at name resolution, the ISP can see exactly which site the user is attempting to connect to, even if they can't see the page. This may be enough to allow blanket blocking of certain categories of site. For example, facebook could be blocked by blocking all requests to facebock.com. This does not allow tampering.